On Thu, Oct 15, 2015 at 4:21 PM Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 15 October 2015 20:33:04 BST, Andrea Faulds <a...@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

Reply via email to