Re: [RFC] Void Return Type (v0.2, reöpeni ng)

On Thu, Oct 15, 2015 at 4:21 PM Rowan Collins <rowan.collins@gmail.com> wrote: > On 15 October 2015 20:33:04 BST, Andrea Faulds <ajf@ajf.me> wrote: > >> Obviously, type hints for internal functions are a bit weird anyway, > >but > >> there's no reason to assume that every function documented as void > >would > >> suddenly be annotated in the Engine as such and start returning > >notices. > > > >Why shouldn't it? For the scalar types, internal and userland functions > behave almost the same. > > Just for the same reason that an existing function that uses bare > "return;" won't automatically be considered "void" - nobody has > explicitly > decided that that's the intent. > > Sure, internal functions whose value shouldn't be used *could* be marked > void, and those would start raising Notices if that was part of void's > behaviour. But there would only be a blizzard of Notices if someone bulk > updated every function in core which happens to return null, which doesn't > seem like an automatic part of creating a void return behaviour. > Especially if the whole point is that "void" signifies something more than > "always returns null". > > Since it's been mentioned a couple of times, I'd like to say that although > the documentation is official, I think it should be considered descriptive > not prescriptive - if it labels something as void, but the Engine doesn't > consider it so, the manual would be wrong, not the Engine. > Could we change the documentation for existing functions to return null, and start using void properly moving forward? Thanks, Korvin