Dan, On Thu, Oct 29, 2015 at 9:22 AM, Dan Ackroyd <dan...@basereality.com> wrote: > Pedro, your email client snipped off the internals CC > > On 29 October 2015 at 13:11, Pedro Cordeiro <pedronar...@gmail.com> wrote: >> If that callback is actually a void function, then using its return value IS >> an error. The same way using a variable you're not sure exists, using a >> return value that you don't know is there is prone to errors. >> >> The weird thing is disallowing even a null return while still silently using >> null as the return value. It makes no sense. >> > > As I said, the current behaviour of PHP of returning a value for all > functions is awesome and eliminates a whole class of errors. > > Adding a pseudo-type that makes people want to break this behaviour is not > good. >
That's not what's happening here though. What's happening is that it's giving the author the ability to say "this function doesn't return anything meaningful". The fact that void gets "converted" to null when you "use" the function isn't a wtf, it's a language rule. Just like C gives you undefined behavior (Though technically you can do it), just like Java gives Class<Void>, TypeScript gives you undefined or null (both pass void). As far as "why not just use null", first off, what other language does that? Many have void return types. I'm not aware of a single one that uses "null" as its "void" return type. I think the bigger WTF would be breaking away from the trend of every other language using "void" rather than saying "well, when you assign a void function to a var you get null". I think the latter is quite clear and easy to explain in documentation. The former would be a bit more of a WTF, especially from others who come from (or go to) other languages. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
