Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On Thu, 15 Oct 2015, Rowan Collins wrote: > Korvin Szanto wrote on 14/10/2015 23:55: > > If I capture the result of a "void" method and check if my result variable > > with isset(), I'll get false. This sounds like it's void of value to me. > > But why "invent" (as far as PHP is concerned) this new keyword of "void" to > mean exactly the same thing "null" already means - absence of a definite > value? It's already "invented" for PHP anyway: http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example 2. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
> Am 19.10.2015 um 11:46 schrieb Derick Rethans: > > On Thu, 15 Oct 2015, Rowan Collins wrote: > >> Korvin Szanto wrote on 14/10/2015 23:55: >>> If I capture the result of a "void" method and check if my result variable >>> with isset(), I'll get false. This sounds like it's void of value to me. >> >> But why "invent" (as far as PHP is concerned) this new keyword of "void" to >> mean exactly the same thing "null" already means - absence of a definite >> value? > > It's already "invented" for PHP anyway: > http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example > 2. > > cheers, > Derick When something is "invented" in Hack, … How is that related to PHP? Hack is a language where a major equal subset is same as in PHP, yes. But that's still not a reason to say it were "invented" for PHP. Please do not use Hack as ultima ratio here, it just is one language like C, Java etc. which happens to have more in common with PHP than most. But it still is just one other language. It's not PHP. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On 16/10/15 01:45, Andrea Faulds wrote: > But why should we change the documentation anyway? We've used void for a > very long time, at least 17 years[0]. We don't just use it in the PHP > manual, it's also used in docblocks and the PHP source code's function > prototypes. It's the commonly-accepted, widely-used term. Until now this > was uncontroversial. This are in my book is just the same as 'NULL'. Different styles of working have different views on how things are interpreted. The function sets for arrays as originally designed simply modified the target object without returning any error code or similar value. The 'more modern' way of doing this may be perhaps to 'return' the array? Or perhaps a count of the number of elements moved - 0 indicates that nothing has changed. I can see the reason you want the run time engine to flag an error if I do $res = sort(xxx); but like many of the 'checks' that seem to be bloating the run time code, I still see that as a function for a good IDE rather than a run time error. void is just a documentational flag that CURRENTLY there is nothing to return, but does not prevent a modified version that may return a value at some point in the future. What is 'controversial' is a change from the freedom of the user to create code the way they want to work, which may wrap a void function in a return check simply because at some point in the future they plan to upgrade the simple off the shelf function call with something which generates the return. I find enforced typing in the same bucket since while some returns may clearly be 'integer' in other cases a later development might use the fractional part for some other purpose. Others seem to think that is bad practice? Having now two different styles of working is something we simply now have to put up with, but loading the bias even more in the direction of 'I think that you are wrong' needs to have a very good case? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Andrea Faulds wrote on 14/10/2015 22:52: Good evening, I'm reviving my Void Return Type RFC, this time for PHP 7.1: https://wiki.php.net/rfc/void_return_type Please read it and tell me your thoughts! My feeling is that it is odd to have both of these be true at once: - void functions can appear in expressions, where the return value is interpreted as null - "return;" and "return null;" are no longer treated as equivalent If the intent is to say "you can use this in an expression, but its value will always be null so there's no point", then "return null;" seems just as valid as "return;", and a typehint of "null" seems to make more sense. I take the point about making intent clear, but can't think of any other interpretation of "this function always returns null" than "this function has no meaningful result". In other words, I can't imagine ever wanting to use "null" to mean something different from "void" in this context. I can see the point in denying the right to say "return some_function_expected_to_return_null();" But in a sense this is no different from declaring that a function returns int, and then writing "return some_function_expected_to_return_int();" If a void function can be used in an expression, it can be used in a return expression, and if so, it feels natural for the type hint to propagate: function foo(): void { do_something(); } function wrapped_foo(): void { do_something_else(); return foo(); } // ERROR: can't specify return value in a void function "return foo()" is not illegal because foo is declared void, but because wrapped_foo is - even though the result is exactly as expected. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On 14 October 2015 at 22:52, Andrea Fauldswrote: > Good evening, > > I'm reviving my Void Return Type RFC, this time for PHP 7.1: > > https://wiki.php.net/rfc/void_return_type > > Please read it and tell me your thoughts! > > Thanks. > > P.S. As it so (fatefully?) happens, I originally introduced this on 14th > February, and it's now 14th October, so it's been exactly 8 months! > > -- > Andrea Faulds > http://ajf.me/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Hi, Semantically, I don't believe that there is sufficient difference between "returns no value" and "returns a value which has been defined as having no value" for us to care about it. The main difference you get between return type of null and a return type of void seems to be some extra fatal errors, for a developer there seems little value. >From a user confusion point of view; PHP currently considers return; and return null; to be equivalent (in fact some code style checkers will replace one with the other) If (and only if) a function has a return type of void these two statements are no longer equivalent - one is a fatal error one is not. For any other return type specification, return null; and return; would behave the same. This in itself would be enough for me to be against adding a return type of void. (also could someone enable my wiki acc: carnage; sent an email ~a week ago and haven't heard back yet :() ~C
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Den 2015-10-14 kl. 23:52, skrev Andrea Faulds: Good evening, I'm reviving my Void Return Type RFC, this time for PHP 7.1: https://wiki.php.net/rfc/void_return_type Please read it and tell me your thoughts! Thanks. P.S. As it so (fatefully?) happens, I originally introduced this on 14th February, and it's now 14th October, so it's been exactly 8 months! Thanks! I have been waiting for this RFC to reopen. Actually wondered why void wasn't among the reserved words in the https://wiki.php.net/rfc/reserve_even_more_types_in_php_7. Regards //Björn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Korvin Szanto wrote on 14/10/2015 23:55: If I capture the result of a "void" method and check if my result variable with isset(), I'll get false. This sounds like it's void of value to me. But why "invent" (as far as PHP is concerned) this new keyword of "void" to mean exactly the same thing "null" already means - absence of a definite value? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Andrea Faulds wrote on 15/10/2015 16:32: Hmm, this is an interesting case you've pointed out. Being able to do `return some_other_void_function();` is something I've desired in other languages. But what if that void function you're calling later adds a return value? Now the calling function is returning a value other than null, violating its type hint and producing a runtime error. Well, fundamentally, this is true of anything short of full type-checking. The type safety below is self-evident: function foo(): int { return 42; } function wrapped_foo(): int { return foo(); } But foo() could later be changed to this: function foo(): string { return 'The Answer'; } The wrapped_foo() typehint is now broken. That's not really any different from foo() starting off as void/returns-null and adding a return value. In both cases, a static analyser could detect the discrepancy, but the Zend Engine will not, until the function is executed. It's a shame there's no "tail call this other function and discard its result" construct. Yeah, I guess what you really want is for a void function to be able to "goto foo();" Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Rowan, Rowan Collins wrote: I can see the point in denying the right to say "return some_function_expected_to_return_null();" But in a sense this is no different from declaring that a function returns int, and then writing "return some_function_expected_to_return_int();" If a void function can be used in an expression, it can be used in a return expression, and if so, it feels natural for the type hint to propagate: function foo(): void { do_something(); } function wrapped_foo(): void { do_something_else(); return foo(); } // ERROR: can't specify return value in a void function "return foo()" is not illegal because foo is declared void, but because wrapped_foo is - even though the result is exactly as expected. Hmm, this is an interesting case you've pointed out. Being able to do `return some_other_void_function();` is something I've desired in other languages. But what if that void function you're calling later adds a return value? Now the calling function is returning a value other than null, violating its type hint and producing a runtime error. It's a shame there's no "tail call this other function and discard its result" construct. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Andrea Faulds wrote on 15/10/2015 16:32: Hi Rowan, Rowan Collins wrote: But why "invent" (as far as PHP is concerned) this new keyword of "void" to mean exactly the same thing "null" already means - absence of a definite value? They don't mean exactly the same thing. null is a value to represent a lack of a value. But there's also the concept of *no value at all* (a missing variable, say). The closest we have to that in PHP already would actually be `unset`, but that's a strange choice given it's not what we use in documentation (function prototypes, PHP manual, PHPDoc, etc. use `void`), and it's tainted by the bizarro `(unset)` cast which casts to null. Oh, lord, not this discussion again! PHP has no concept of a variable being in the "state" of unset; it has programmer hints to warn you if you read before writing, and a couple of odd constructs which let you access the current symbol table as a dictionary. The manual has some weird wording in places which implies that a variable takes on a type when first used, but in practice the rule is much simpler: any variable which hasn't had a value assigned yet is considered to have the value NULL, and normal cast rules apply from there. The same is true of missing array keys, object properties, unset() variables, unspecified return values, etc, etc, etc. They are all NULL. You could add a warning for "function foo() { return; } $a = foo();" to match "$x = []; $a = $x['foo'];", but $a would still unambiguously contain the value NULL in both cases, and outside of some odd applications like templating, it is *values* the program should be concerned with, not the *reason* for those values. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Rowan, Rowan Collins wrote: But why "invent" (as far as PHP is concerned) this new keyword of "void" to mean exactly the same thing "null" already means - absence of a definite value? They don't mean exactly the same thing. null is a value to represent a lack of a value. But there's also the concept of *no value at all* (a missing variable, say). The closest we have to that in PHP already would actually be `unset`, but that's a strange choice given it's not what we use in documentation (function prototypes, PHP manual, PHPDoc, etc. use `void`), and it's tainted by the bizarro `(unset)` cast which casts to null. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. $a = $b; //$b wasn't initiated. This does the same thing. I tried accessing what was supposed to be 'nothing' ($b), and got NULL with an E_NOTICE being thrown. function myFunc() : void { ... } $a = myFunc(); I see no reason why this should silently assign NULL to $a, *specially* with "return null;" being explicitly forbidden. My point is: we already use an implicit NULL return on functions with missing return values (or with "return ;"), but now we're explicitly prohibiting even a NULL return. The behaviour should be consistent (NULL should be accessed, as for all undefined things), with an E_NOTICE. function myFunc() { return ; } $a = myFunc(); Should assign NULL to $a and *not* throw an E_NOTICE (this is the current status), because a return type was not forbidden with the keyword 'void'. 2015-10-15 13:00 GMT-03:00 Rowan Collins: > Andrea Faulds wrote on 15/10/2015 16:32: > >> Hmm, this is an interesting case you've pointed out. Being able to do >> `return some_other_void_function();` is something I've desired in other >> languages. >> >> But what if that void function you're calling later adds a return value? >> Now the calling function is returning a value other than null, violating >> its type hint and producing a runtime error. >> > > Well, fundamentally, this is true of anything short of full type-checking. > The type safety below is self-evident: > > function foo(): int { return 42; } > function wrapped_foo(): int { return foo(); } > > But foo() could later be changed to this: > > function foo(): string { return 'The Answer'; } > > The wrapped_foo() typehint is now broken. That's not really any different > from foo() starting off as void/returns-null and adding a return value. > > In both cases, a static analyser could detect the discrepancy, but the > Zend Engine will not, until the function is executed. > > > It's a shame there's no "tail call this other function and discard its >> result" construct. >> > > Yeah, I guess what you really want is for a void function to be able to > "goto foo();" > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hey Chris, Chris Riley wrote: Semantically, I don't believe that there is sufficient difference between "returns no value" and "returns a value which has been defined as having no value" for us to care about it. The main difference you get between return type of null and a return type of void seems to be some extra fatal errors, for a developer there seems little value. From a user confusion point of view; PHP currently considers return; and return null; to be equivalent (in fact some code style checkers will replace one with the other) If (and only if) a function has a return type of void these two statements are no longer equivalent - one is a fatal error one is not. For any other return type specification, return null; and return; would behave the same. This in itself would be enough for me to be against adding a return type of void. This is true, but `void` isn't an ordinary return type. It exists to ensure a function doesn't return anything, unlike other return types which exist to ensure a function returns a specific thing. `return null;` is *technically* equivalent to `return;`, but it's not quite the same in intent, usually. We could special-case it and allow it, but why? The return value isn't supposed to be used, why should we allow you to specify it? A void function in PHP does technically produce a result of null, but it might as well be false or -1 or whatever for all we care. Also, if `return null;` is to work, should `return(null);` also work? How about `return \null;`? `return SOME_NULL_CONSTANT;`? It seems silly to me since, again, the return value is insigificant. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Larry, Larry Garfield wrote: On 10/14/2015 06:30 PM, Andrea Faulds wrote: This would be strange. The manual doesn't say `null`, and I can't think of any language which uses `null` as the return type in this situation, even when they have the same implicit-null-return behaviour that PHP has (see the email you're replying to). Also, wouldn't you expect this to behave like existing type hints, and let you return a null value from any source? But that's not what you would actually want, right? Thanks. Well, that depends on the intent here. In practice, is the intent to add a "no return at all" type of function (ie, $a = foo() is a syntax error now where it was not before), or to make it explicit that the only legal return is null (even if implicitly that means having a non-early return statement is pointless)? Those are the two options. That may or may not dictate the keyword that gets used. It would seem ideal to have "true" void functions which can't be used as expressions, i.e. producing an error if you try to use them like in your example. But they'd cause a backwards-compatibility headache, and I'm not sure they're a good idea anyway. Every function call being an expression is pretty handy. You can safely capture the return value of a callback and pass it along, for instance. In a sense, what this RFC offers might be called a compromise. It enforces the rules of `void` within the function, but at the end of the day the caller still gets a null out of it since that's what PHP's always done. It definitely sounds like you're favoring the second (as that's what the RFC says). Which may or make not make "void" an odd keyword to choose when what's actually happening is NULL getting returned. Is NULL a void? (There's a deep philosophical question...) It's an interesting question. There's some precedent for using `void` in this way even though the functions aren't "truly" void. I mostly like `void` because it's the customary keyword to use, though. Everyone knows what a 'void function' is. As I said, I don't have a strong opinion on the subject yet. I'm just trying to distil the discussion down to as small a question as possible. :-) I appreciate your efforts. I have a tendency to be a bit verbose in my writing, so providing clarity is helpful. :) Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On 10/15/2015 01:19 AM, Larry Garfield wrote: On 10/14/2015 06:00 PM, Andrea Faulds wrote: >> Both you and Stas have said this, but it's only true if we solely >> consider C-like languages. Other languages do different things. In >> the PHP manual, Hack, TypeScript, ActionScript, and most likely other >> languages (these are just off the top of my head), `void` functions >> do still have an implicit result. >> >> All of these languages would have had the choice to do what you're >> suggesting and use `null`, or its equivalent (`undefined` for >> TypeScript and ActionScript). They didn't. Why? If I had to guess, >> there's at least three reasons. For one, void is the word languages >> usually use for this. For another, `void` and `null` they mean >> different things. `void` signifies a function isn't returning >> anything. `null` signifies a function that *returns null*, regardless >> of where that null came from. `function foo(): null { return >> some_probably_null_returning_function(); }` should surely be legal >> with a `null` type hint, yet it's nonsensical code. Finally, making a >> function truly "return nothing", i.e. disallowing its use as an >> expression/rvalue, breaks some use cases, like passing along the >> result of a callback. >> >> PHP would neither be the first nor the last to be using `void` in >> this way. >> >>> If the union types RFC[2] passes it >>> makes sense to allow `Foo | null` which allows something of type `Foo` >>> or `null`. To me it makes sense that if you then remove `Foo` you are >>> left with `null`, not `void`. My personal recommendation because of >>> this would be to use `null` for the return type and instead of `void`. >> >> `null` would be a weird type, because it doesn't make sense as a >> parameter type, and as a return type, you don't really want to >> enforce returning null, you want to enforce not returning at all (see >> the example above). It feels like a poor man's substitute to me. >> >> Thanks. > > The tricky part here is that saying a function does not return is not > something PHP currently does: > > https://3v4l.org/HtAuC > > No return implicitly returns NULL, which you can assign to a variable > if, for some strange reason, you were so inclined. So this would be > more than "just" a syntactic documentation feature. > > Which I believe gives the following options: > > 1) Change the language behavior such that > > function foo() : void { ...} > $a = foo(); > > Is a syntax error (because there really was nothing returned to > assign), rather than resulting in $a having a value of NULL. > > 2) Use null as a "type" (which I agree feels weird just saying it), > such that: > > function foo() : null { ...} > $a = foo(); > > and > > function foo() { ...} > $a = foo(); > > are identical. The former would impact the contents of the function > (eg, a non-empty return would be a parse error), but the external > result is the same ($a == NULL). > > 3) Use the "void" keyword, but give it the same effect as option 2. > > The RFC currently seems to propose option 3 (based on the "Use of void > functions in expressions" section). I don't have a strong feeling at > this point about which option I'd prefer. > Option 4) // implicit return void function foo () { return; } // explicit return void function foo () : void { return; }; // syntax error if returning something on explicit return void function foo () : void { return null; }; // syntax error on using return value of explicit return void function foo () : void { return; }; $bar = foo(); // return NULL on implicit return void (this could also give a warning/notice/deprecated error) function foo () { return; }; $bar = foo(); // NULL // mixing return void with any other return values could also result in a warning/notice/deprecated error function foo () { if ($bar) return; return $bar; }; --Larry Garfield > I really like this as in my opinion if a function doesn't return something it should be part of the function signature and it really helps to avoid mistakes on writing code. Marc
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On 15 October 2015 20:33:04 BST, Andrea Fauldswrote: >> 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. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On Thu, Oct 15, 2015 at 4:21 PM Rowan Collinswrote: > On 15 October 2015 20:33:04 BST, Andrea Faulds 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
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Korvin, Korvin Szanto wrote: Could we change the documentation for existing functions to return null, and start using void properly moving forward? As I have stated several times now, we're not "misusing" void. PHP is not the only language to use the word in this manner. But why should we change the documentation anyway? We've used void for a very long time, at least 17 years[0]. We don't just use it in the PHP manual, it's also used in docblocks and the PHP source code's function prototypes. It's the commonly-accepted, widely-used term. Until now this was uncontroversial. Why should we move heaven and earth when there's nothing wrong? [0] https://web.archive.org/web/19991002011107/http://php.net/manual/function.sort.php3 -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hey Chris, Chris Riley wrote: Semantically, I don't believe that there is sufficient difference between "returns no value" and "returns a value which has been defined as having no value" for us to care about it. The main difference you get between return type of null and a return type of void seems to be some extra fatal errors, for a developer there seems little value. From a user confusion point of view; PHP currently considers return; and return null; to be equivalent (in fact some code style checkers will replace one with the other) If (and only if) a function has a return type of void these two statements are no longer equivalent - one is a fatal error one is not. For any other return type specification, return null; and return; would behave the same. This in itself would be enough for me to be against adding a return type of void. This is true, but `void` isn't an ordinary return type. It exists to ensure a function doesn't return anything, unlike other return types which exist to ensure a function returns a specific thing. `return null;` is *technically* equivalent to `return;`, but it's not quite the same in intent, usually. We could special-case it and allow it, but why? The return value isn't supposed to be used, why should we allow you to specify it? A void function in PHP does technically produce a result of null, but it might as well be false or -1 or whatever for all we care. Also, if `return null;` is to work, should `return(null);` also work? How about `return \null;`? `return SOME_NULL_CONSTANT;`? It seems silly to me since, again, the return value is insigificant. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Pedro, Pedro Cordeiro wrote: I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. We could do this, but I do wonder if it might cause a lot of E_NOTICEs to pop up for existing code, assuming we applied this to built-in PHP functions. I'm not sure. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On 15 October 2015 at 16:32, Andrea Fauldswrote: > In a sense, what this RFC offers might be called a compromise. It enforces > the rules of `void` within the function, but at the end of the day the > caller still gets a null out of it since that's what PHP's always done. > > > If this truly is the case, then all you get over hinting void as the return type instead of null is a fatal error for return null; Sure you can argue for capturing intent but realistically the difference in intent between 'returns no value' and 'does not return a value' is something for philosophers to argue over not programmers. ;)
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
> > this would make the "void" keyword feel more meaningful. I, too, had issues trying to understand what "void" was bringing to the table. IMHO, it should warn people thinking some specific function/method returns a value when it doesn't, not protect against some dev forgetting the function he's writing should not return something. IMHO, it's far more important to warn "Hey, this function returns NOTHING, don't try to use its value because it doesn't exist!" then it is to warn "Hey, this function can't return anything, stop trying to return things!". Throwing an E_NOTICE when accessing a void return value would make perfect sense, as the compiler would strict check that the function author defined a no-return and indeed returned nothing and would also warn whoever was calling the function that it doesn't return anything. > We could do this, but I do wonder if it might cause a lot of E_NOTICEs to pop up for existing code, assuming we applied this to built-in PHP functions. My proposal is to only throw an E_NOTICE when accessing a return value from a function that is explicitly marked with "void". A function with no return ("return ;") but with no ": void" on the signature would not necessarily throw an E_NOTICE. function myFunc() { return ; } $a = myFunc(); //NULL should be assigned to $a silently, like it is today. function myOtherFunc() : void { return ; } $b = myOtherFunc(); //NULL should be assigned to $b, but an E_NOTICE is thrown. 2015-10-15 13:34 GMT-03:00 Andrea Faulds: > Hi Pedro, > > Pedro Cordeiro wrote: > >> I've been thinking about what PHP should do when accessing the return >> value >> of a `void` function, and so far, I think the consistent thing should be >> to >> get NULL, while throwing an E_NOTICE. >> > > We could do this, but I do wonder if it might cause a lot of E_NOTICEs to > pop up for existing code, assuming we applied this to built-in PHP > functions. > > I'm not sure. > > Thanks. > -- > Andrea Faulds > http://ajf.me/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Pedro Cordeiro wrote on 15/10/2015 17:14: I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. $a = $b; //$b wasn't initiated. This does the same thing. I tried accessing what was supposed to be 'nothing' ($b), and got NULL with an E_NOTICE being thrown. function myFunc() : void { ... } $a = myFunc(); I see no reason why this should silently assign NULL to $a, *specially* with "return null;" being explicitly forbidden. ... The behaviour should be consistent (NULL should be accessed, as for all undefined things), with an E_NOTICE. I don't know how easy this would be to implement, but I agree that this would make the "void" keyword feel more meaningful. Does the Engine have a way to know whether a return value is being used or discarded for optimisation purposes? If so, could that logic be hooked to provide the Notice? Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Andrea Faulds wrote on 15/10/2015 17:34: Hi Pedro, Pedro Cordeiro wrote: I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. We could do this, but I do wonder if it might cause a lot of E_NOTICEs to pop up for existing code, assuming we applied this to built-in PHP functions. I'm not sure. The way Pedro described it, it wouldn't apply to any existing functions because they wouldn't be declared void. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Den 2015-10-15 kl. 09:04, skrev Björn Larsson: Den 2015-10-14 kl. 23:52, skrev Andrea Faulds: Good evening, I'm reviving my Void Return Type RFC, this time for PHP 7.1: https://wiki.php.net/rfc/void_return_type Please read it and tell me your thoughts! Thanks. P.S. As it so (fatefully?) happens, I originally introduced this on 14th February, and it's now 14th October, so it's been exactly 8 months! Thanks! I have been waiting for this RFC to reopen. Actually wondered why void wasn't among the reserved words in the https://wiki.php.net/rfc/reserve_even_more_types_in_php_7. Regards //Björn Hm... Just noticed that HACK allows void as return type. Wonder how it works and motivation for having it? Mention in RFC? //Björn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Rowan, Rowan Collins wrote: Andrea Faulds wrote on 15/10/2015 17:34: Hi Pedro, Pedro Cordeiro wrote: I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. We could do this, but I do wonder if it might cause a lot of E_NOTICEs to pop up for existing code, assuming we applied this to built-in PHP functions. I'm not sure. The way Pedro described it, it wouldn't apply to any existing functions because they wouldn't be declared void. 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. I'd like there the two to converge, not diverge. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On Wed, Oct 14, 2015 at 4:46 PM, Levi Morrisonwrote: > > > I agree that `void` doesn't make sense given that we document that > `return;` will return null[1]. If the union types RFC[2] passes it > makes sense to allow `Foo | null` which allows something of type `Foo` > or `null`. To me it makes sense that if you then remove `Foo` you are > left with `null`, not `void`. My personal recommendation because of > this would be to use `null` for the return type and instead of `void`. > > Also, I do not think this feature is pointless. For instance, it has > value in interfaces. Declaring that a method does not return a value > means implementors cannot accidentally return something. This is > better than just documenting that it should not be done. +1 these are my thoughts exactly. I would be for it if it was null, and interfaces is exactly why I would be for it.
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi! > I'm reviving my Void Return Type RFC, this time for PHP 7.1: > > https://wiki.php.net/rfc/void_return_type > > Please read it and tell me your thoughts! I still see no point in this, as every PHP function actually returns something (at least null). So this type would not actually be right and would not reflect what actually is happening. Moreover, I don't see any scenario where some code depends on a function not returning something explicitly (i.e. does not use return value) but function actually returns something explicitly and the calling code breaks. This appears to be impossible, and thus there's no reason to declare a function "void" except purely for documentation purposes. Adding keywords to the language just to document this does not look to me like a good idea. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Levi, Levi Morrison wrote: On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshevwrote: Hi! I'm reviving my Void Return Type RFC, this time for PHP 7.1: https://wiki.php.net/rfc/void_return_type Please read it and tell me your thoughts! I still see no point in this, as every PHP function actually returns something (at least null). So this type would not actually be right and would not reflect what actually is happening. I agree that `void` doesn't make sense given that we document that `return;` will return null[1]. Both you and Stas have said this, but it's only true if we solely consider C-like languages. Other languages do different things. In the PHP manual, Hack, TypeScript, ActionScript, and most likely other languages (these are just off the top of my head), `void` functions do still have an implicit result. All of these languages would have had the choice to do what you're suggesting and use `null`, or its equivalent (`undefined` for TypeScript and ActionScript). They didn't. Why? If I had to guess, there's at least three reasons. For one, void is the word languages usually use for this. For another, `void` and `null` they mean different things. `void` signifies a function isn't returning anything. `null` signifies a function that *returns null*, regardless of where that null came from. `function foo(): null { return some_probably_null_returning_function(); }` should surely be legal with a `null` type hint, yet it's nonsensical code. Finally, making a function truly "return nothing", i.e. disallowing its use as an expression/rvalue, breaks some use cases, like passing along the result of a callback. PHP would neither be the first nor the last to be using `void` in this way. If the union types RFC[2] passes it makes sense to allow `Foo | null` which allows something of type `Foo` or `null`. To me it makes sense that if you then remove `Foo` you are left with `null`, not `void`. My personal recommendation because of this would be to use `null` for the return type and instead of `void`. `null` would be a weird type, because it doesn't make sense as a parameter type, and as a return type, you don't really want to enforce returning null, you want to enforce not returning at all (see the example above). It feels like a poor man's substitute to me. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Stas, Stanislav Malyshev wrote: I still see no point in this, as every PHP function actually returns something (at least null). So this type would not actually be right and would not reflect what actually is happening. It wouldn't be incorrect. Not all languages with `void` prevent a function's use as an expression (or 'rvalue' in C parlance). In some, it merely requires the function not to explicitly return a value. And, heck, we use void in the PHP manual all the time. Moreover, I don't see any scenario where some code depends on a function not returning something explicitly (i.e. does not use return value) but function actually returns something explicitly and the calling code breaks. This appears to be impossible, It most likely is, but it's not the only case that matters. What if you mistakenly return a value in a function that's not supposed to? This would catch you out. and thus there's no reason to declare a function "void" except purely for documentation purposes. Adding keywords to the language just to document this does not look to me like a good idea. I feel that the basic facts about a function should be in the signature, and shouldn't have to be hidden in a comment, if only because it's more concicse and keeps information about parameters on the same line as the parameters themselves. Unlike comments, type hints can't lie, because they're actually enforced. But, yes, it is mostly just useful for documentation. I can understand your objection there. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi! > And, heck, we use void in the PHP manual all the time. Yes, because PHP manual *is* the documentation :) Note that function descriptions in the manual, while they are similar to PHP syntax, aren't actually valid PHP, even after scalar typing introduction. Bizarrely enough, they don't even match the return type syntax. > It most likely is, but it's not the only case that matters. What if you > mistakenly return a value in a function that's not supposed to? This > would catch you out. Why would I care about such a mistake? Why would I care so much that I would need a special language-level construct to catch it? How many such mistakes happen and are they critical enough to have the engine bothering with going after them? I think such mistakes are extremely rare and insignificant. > I feel that the basic facts about a function should be in the signature, > and shouldn't have to be hidden in a comment, if only because it's more I guess we disagree here, because I do not think comments are "hidden", and I do not think signature of the function should be the comment. In fact, in Java for example (which seems to be the model language for the strict typing aficionados) it is long standing best practice to actually verify the javadoc comments as part of the build and fail the build if they are missing or wrong. I am not advocating for doing (or not doing :) this in PHP, but I do say documentation is not "hidden" and strict typing is not the same as documentation. Moreover, in this case strict typing implies something that is outright false - the function that is declared void does return a value, namely null. Even worse, if you do try to return exactly the same value, the RFC requires failure in this case, which makes zero sense as precisely the same thing happens in both cases. > concicse and keeps information about parameters on the same line as the > parameters themselves. Unlike comments, type hints can't lie, because > they're actually enforced. In fact, it is the opposite - as I said above, that particular type does lie, and it has to, because what it tries to express actually does not exist in PHP. I might be reluctantly ok with tolerating purely documentation type, but tolerating purely documentation type that is in fact untrue does not look good to me. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On Wed, Oct 14, 2015 at 3:47 PM Levi Morrisonwrote: > On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev > wrote: > > Hi! > > > >> I'm reviving my Void Return Type RFC, this time for PHP 7.1: > >> > >> https://wiki.php.net/rfc/void_return_type > >> > >> Please read it and tell me your thoughts! > > > > I still see no point in this, as every PHP function actually returns > > something (at least null). So this type would not actually be right and > > would not reflect what actually is happening. > > I agree that `void` doesn't make sense given that we document that > `return;` will return null[1]. If the union types RFC[2] passes it > makes sense to allow `Foo | null` which allows something of type `Foo` > or `null`. To me it makes sense that if you then remove `Foo` you are > left with `null`, not `void`. My personal recommendation because of > this would be to use `null` for the return type and instead of `void`. > Isn't null supposed to mean the absense of a value and not take the place of a value in PHP though? Didn't we just have a long conversation about this in a thread about PHPSadness? If I capture the result of a "void" method and check if my result variable with isset(), I'll get false. This sounds like it's void of value to me. > Also, I do not think this feature is pointless. For instance, it has > value in interfaces. Declaring that a method does not return a value > means implementors cannot accidentally return something. This is > better than just documenting that it should not be done. > This is what I was thinking too, I'm not sure that there's much value beyond that > [1]: http://php.net/manual/en/function.return.php > [2]: https://wiki.php.net/rfc/union_types > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshevwrote: > Hi! > >> I'm reviving my Void Return Type RFC, this time for PHP 7.1: >> >> https://wiki.php.net/rfc/void_return_type >> >> Please read it and tell me your thoughts! > > I still see no point in this, as every PHP function actually returns > something (at least null). So this type would not actually be right and > would not reflect what actually is happening. I agree that `void` doesn't make sense given that we document that `return;` will return null[1]. If the union types RFC[2] passes it makes sense to allow `Foo | null` which allows something of type `Foo` or `null`. To me it makes sense that if you then remove `Foo` you are left with `null`, not `void`. My personal recommendation because of this would be to use `null` for the return type and instead of `void`. Also, I do not think this feature is pointless. For instance, it has value in interfaces. Declaring that a method does not return a value means implementors cannot accidentally return something. This is better than just documenting that it should not be done. [1]: http://php.net/manual/en/function.return.php [2]: https://wiki.php.net/rfc/union_types -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On 10/14/2015 06:00 PM, Andrea Faulds wrote: Both you and Stas have said this, but it's only true if we solely consider C-like languages. Other languages do different things. In the PHP manual, Hack, TypeScript, ActionScript, and most likely other languages (these are just off the top of my head), `void` functions do still have an implicit result. All of these languages would have had the choice to do what you're suggesting and use `null`, or its equivalent (`undefined` for TypeScript and ActionScript). They didn't. Why? If I had to guess, there's at least three reasons. For one, void is the word languages usually use for this. For another, `void` and `null` they mean different things. `void` signifies a function isn't returning anything. `null` signifies a function that *returns null*, regardless of where that null came from. `function foo(): null { return some_probably_null_returning_function(); }` should surely be legal with a `null` type hint, yet it's nonsensical code. Finally, making a function truly "return nothing", i.e. disallowing its use as an expression/rvalue, breaks some use cases, like passing along the result of a callback. PHP would neither be the first nor the last to be using `void` in this way. If the union types RFC[2] passes it makes sense to allow `Foo | null` which allows something of type `Foo` or `null`. To me it makes sense that if you then remove `Foo` you are left with `null`, not `void`. My personal recommendation because of this would be to use `null` for the return type and instead of `void`. `null` would be a weird type, because it doesn't make sense as a parameter type, and as a return type, you don't really want to enforce returning null, you want to enforce not returning at all (see the example above). It feels like a poor man's substitute to me. Thanks. The tricky part here is that saying a function does not return is not something PHP currently does: https://3v4l.org/HtAuC No return implicitly returns NULL, which you can assign to a variable if, for some strange reason, you were so inclined. So this would be more than "just" a syntactic documentation feature. Which I believe gives the following options: 1) Change the language behavior such that function foo() : void { ...} $a = foo(); Is a syntax error (because there really was nothing returned to assign), rather than resulting in $a having a value of NULL. 2) Use null as a "type" (which I agree feels weird just saying it), such that: function foo() : null { ...} $a = foo(); and function foo() { ...} $a = foo(); are identical. The former would impact the contents of the function (eg, a non-empty return would be a parse error), but the external result is the same ($a == NULL). 3) Use the "void" keyword, but give it the same effect as option 2. The RFC currently seems to propose option 3 (based on the "Use of void functions in expressions" section). I don't have a strong feeling at this point about which option I'd prefer. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
On 10/14/2015 06:30 PM, Andrea Faulds wrote: Which I believe gives the following options: 1) Change the language behavior such that function foo() : void { ...} $a = foo(); Is a syntax error (because there really was nothing returned to assign), rather than resulting in $a having a value of NULL. As the RFC notes, this breaks things, and is inconsistent with how PHP already does things. 2) Use null as a "type" (which I agree feels weird just saying it), such that: function foo() : null { ...} $a = foo(); and function foo() { ...} $a = foo(); are identical. The former would impact the contents of the function (eg, a non-empty return would be a parse error), but the external result is the same ($a == NULL). This would be strange. The manual doesn't say `null`, and I can't think of any language which uses `null` as the return type in this situation, even when they have the same implicit-null-return behaviour that PHP has (see the email you're replying to). Also, wouldn't you expect this to behave like existing type hints, and let you return a null value from any source? But that's not what you would actually want, right? Thanks. Well, that depends on the intent here. In practice, is the intent to add a "no return at all" type of function (ie, $a = foo() is a syntax error now where it was not before), or to make it explicit that the only legal return is null (even if implicitly that means having a non-early return statement is pointless)? Those are the two options. That may or may not dictate the keyword that gets used. It definitely sounds like you're favoring the second (as that's what the RFC says). Which may or make not make "void" an odd keyword to choose when what's actually happening is NULL getting returned. Is NULL a void? (There's a deep philosophical question...) As I said, I don't have a strong opinion on the subject yet. I'm just trying to distil the discussion down to as small a question as possible. :-) Cheers. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)
Hi Larry, Larry Garfield wrote: The tricky part here is that saying a function does not return is not something PHP currently does: https://3v4l.org/HtAuC No return implicitly returns NULL, which you can assign to a variable if, for some strange reason, you were so inclined. So this would be more than "just" a syntactic documentation feature. Which has been pointed out. Which I believe gives the following options: 1) Change the language behavior such that function foo() : void { ...} $a = foo(); Is a syntax error (because there really was nothing returned to assign), rather than resulting in $a having a value of NULL. As the RFC notes, this breaks things, and is inconsistent with how PHP already does things. 2) Use null as a "type" (which I agree feels weird just saying it), such that: function foo() : null { ...} $a = foo(); and function foo() { ...} $a = foo(); are identical. The former would impact the contents of the function (eg, a non-empty return would be a parse error), but the external result is the same ($a == NULL). This would be strange. The manual doesn't say `null`, and I can't think of any language which uses `null` as the return type in this situation, even when they have the same implicit-null-return behaviour that PHP has (see the email you're replying to). Also, wouldn't you expect this to behave like existing type hints, and let you return a null value from any source? But that's not what you would actually want, right? Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Void Return Type
Hi, De : Andrea Faulds [mailto:a...@ajf.me] following codes still works: $b = a(); so, if you want a void return type, and if you want it to be a useful feature.. above expr should be invalid with an error a() return nothing I'm not sure about this. PHP has always made functions valid rvalues, for better or for worse. This RFC could make void functions truly void What about renaming this hint to 'null', instead of 'void'. I know that it supports no explicit return and 'return;' with no value but what it does is more checking that return value is null, than checking return value is 'void', whose concept is not defined yet. It would remove the ambiguity on the fact that the return value is used or not. The only justification is that, in PHP, not returning an explicit value, or using 'return;' returns null, that's history, period. I think it would make the concept easier to understand and would reserve the ambiguous 'void' keyword for the future, if it finds a utility one day. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hey François, On 14 Feb 2015, at 04:57, François Laupretre franc...@php.net wrote: That's a nice addition and a beginning to distinguish void from null, as I imagine the function still returns null. Now, what about making void a real zval type ? It would open a lot of possibilities. Unlike null, conversions from void would raise an error. It would also be rejected as argument input type but could be used as an output type when arg is passed by ref, it could be the default type for return_value (huge BC break here) and so on... We could do this, but for the longest time we've made all functions have some return value, even ones which don't explicitly return one (they return NULL). I think it'd be better not to change this. I expect IDEs and such could earn you about it, though. There's a need for a real 'no value' type different from null, as null has too many uses. If defined correctly, it can be a powerful addition. If I was to go back to 1994, I'd add undefined to PHP like JS has. Today, though, I think that is unrealistic, as much as I wish it wasn't. A void type only really makes sense as a pseudo-type for return type checking purposes, IMO. Thanks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi, On 14 Feb 2015, at 03:32, reeze re...@php.net wrote: Do we really have to throw an catchable fatal error? the other return types make sense, why so strict? We throw E_RECOVERABLE_ERROR for all type errors, both for parameters and return types. It's not anything new. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
On Sat, Feb 14, 2015 at 12:26:08PM +, Andrea Faulds wrote: We could do this, but for the longest time we've made all functions have some return value, even ones which don't explicitly return one (they return NULL). I think it'd be better not to change this. I expect IDEs and such could earn you about it, though. All *existing* functions have a return value. That would not change. If someone makes one of their functions void then where they use it could not be where a value is needed. So: expect it in new code; but in 5 years time that code will be mature. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi, On 14 Feb 2015, at 05:03, Xinchen Hui larue...@php.net wrote: Hey: be honest, I think it's only part of the idea is implemented. which make it useless. in PHP, even if you don't return anything, NULL is returned implicitly. even if a function is declared return nothing(void). like: function a() : void {}; following codes still works: $b = a(); so, if you want a void return type, and if you want it to be a useful feature.. above expr should be invalid with an error a() return nothing I'm not sure about this. PHP has always made functions valid rvalues, for better or for worse. This RFC could make void functions truly void, but that would be a massive change to support value-less function returns. It would also break existing code which assumes all functions return a value, which isn't good. I think this RFC is enough: it would let you enforce that a function doesn't return anything and makes code more self-documenting. It doesn't affect anything trying to use the function's implicit return value of NULL, but IDEs and code linters would surely pick up on it for you. It's still useful even if it doesn't bind the caller. Thanks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi, On 14 Feb 2015, at 05:54, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I'm not sure what it is useful for, exactly. I mean, the more fatal errors the merrier, but I fail to see what exactly use except having yet more cases when your code may break it provides. I mean, if you defined a void function, that means you're not using it return value anywhere. Then who cares what return statement says? What would be the point of *allowing* returning a value? It's clearly an error. We could let you return anything and then discard it, but now you won't spot the error in your code. Additionally, this RFC gets inheritance wrong - having return from function that previously did not return anything is not a violation of contract, since there's no practical contract that can rely on function not returning anything (in fact, there's no way in PHP to even check that AFAIK). I am wondering about inheritance as well. I thought of void as having no subclass. But it's not really a return type for our purposes, it's more like a declaration that a function doesn't return anything. So, I guess inheritance should allow removing or changing the typehint if it is void. I might need more opinions on this first, though. Summarily, this seems to me an exercise in strictness for the sake of strictness. There are languages that force people to abide by a lot of rules because their creators believe more rules is the same as better code, but PHP never was one of them and the fact there are so many people trying to make PHP that makes me sad. It's not merely for the sake of it. It makes function signatures more descriptive, and lets you catch bugs in your code. We already use void in the manual: why not in PHP? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi! What would be the point of *allowing* returning a value? It's clearly It's an error only because you declared it an error. an error. We could let you return anything and then discard it, but now you won't spot the error in your code. Function return values which are going unused all the time. In PHP, functions are very frequently called for side effects and not return values. So returning value and discarding it is a common and perfectly valid scenario. And it also has absolutely nothing to do with void declaration - void declaration doesn't cause discarding the value and you can discard the value with or without it. It's not merely for the sake of it. It makes function signatures more descriptive, and lets you catch bugs in your code. Only bug it can catch is wrongly declaring the function to be void - which is introduced by this RFC. For me, it is a clear case of generating error for the sake of error. We already use void in the manual: why not in PHP? Because the manual is the *documentation*, not code. It explains that the function does not return anything useful. It's not the same as creating an error when function returns something useful. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
On Sat, Feb 14, 2015 at 3:28 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! What would be the point of *allowing* returning a value? It's clearly It's an error only because you declared it an error. an error. We could let you return anything and then discard it, but now you won't spot the error in your code. Function return values which are going unused all the time. In PHP, functions are very frequently called for side effects and not return values. So returning value and discarding it is a common and perfectly valid scenario. And it also has absolutely nothing to do with void declaration - void declaration doesn't cause discarding the value and you can discard the value with or without it. It's not merely for the sake of it. It makes function signatures more descriptive, and lets you catch bugs in your code. Only bug it can catch is wrongly declaring the function to be void - which is introduced by this RFC. For me, it is a clear case of generating error for the sake of error. We already use void in the manual: why not in PHP? Because the manual is the *documentation*, not code. It explains that the function does not return anything useful. It's not the same as creating an error when function returns something useful. One of the primary purposes of having typehints *is* documentation. This applies both to our existing type annotations, to the newly introduced return declarations - and to the void return type. The advantage of having the type declaration be part of the language (rather than a docblock) is brevity on one hand and verification of its correctness on the other hand. It's easy to forget to update docblock type annotations, but you can't get away with specifying an incorrect language-supported annotations - if you use a wrong type annotation your code just won't work. The void return type is actually the one case where we can at compile-time fully verify that it is used correctly - which is great. Allowing to return a value from a void function doesn't make sense. If you want to return a value, don't declare it as void. If you declare it as void, don't return a value. It's really as simple as that. Nikita
Re: [PHP-DEV] [RFC] Void Return Type
On Feb 14, 2015 6:28 AM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! What would be the point of *allowing* returning a value? It's clearly It's an error only because you declared it an error. an error. We could let you return anything and then discard it, but now you won't spot the error in your code. Function return values which are going unused all the time. In PHP, functions are very frequently called for side effects and not return values. So returning value and discarding it is a common and perfectly valid scenario. And it also has absolutely nothing to do with void declaration - void declaration doesn't cause discarding the value and you can discard the value with or without it. I have no strong opinion on the void but reading this exact comment makes me think that there is clearly an issue here. How ignoring values is a perfectly valid scenario? Yes, there are cases where some code does not need it but it is clearly not clean nor correct. It's not merely for the sake of it. It makes function signatures more descriptive, and lets you catch bugs in your code. Only bug it can catch is wrongly declaring the function to be void - which is introduced by this RFC. For me, it is a clear case of generating error for the sake of error. No. It makes clear about what happens and what should be expected. I see it as a complement to the return type rfc. We already use void in the manual: why not in PHP? Because the manual is the *documentation*, not code. It explains that the function does not return anything useful. It's not the same as creating an error when function returns something useful. I did not check the implementation yet but I suppose it does not default to void, f.e. for existing codes. So I do not see about which errors you are talking about here. However yes, future codes (lib, apps, etc) using void will create this error and it will be pretty easy to make the caller happy, no? A common thing I see lately is to look at legacy code to consider what should or can be php tomorrow. I consider it as a strategic mistake. I am not saying we should drastically change php or force users to rely on new paradigms. But we must provide features to make php relevant for a wider audience. And it is possible to do it without making it less easy to use. We had the same discussion about OO when we developed 5.0, see where we are now. Stronger than ever. Cheers, Pierre
Re: [PHP-DEV] [RFC] Void Return Type
Hi! One of the primary purposes of having typehints *is* documentation. This Documentation causing fatal errors is something quite unusual. And wrong. applies both to our existing type annotations, to the newly introduced That is not true, for existing types documentation is not the only and not the primary purpose. Primary purpose is ensuring the method gets the value it expects. Otherwise phpdoc would be enough. return declarations - and to the void return type. The advantage of having the type declaration be part of the language (rather than a docblock) is brevity on one hand and verification of its correctness on the other hand. It's easy to forget to update docblock type annotations There's absolutely no brevity advantage and verification, as I mentioned, in this case is not very useful. The void return type is actually the one case where we can at compile-time fully verify that it is used correctly - which is great. No, you can not, since you have no idea how your function is used and where. Allowing to return a value from a void function doesn't make sense. If Having language-enforced concept of void function in PHP doesn't make sense. PHP functions always return values, and verifying that function pretends to not return value has no use, as no code can depend on it. you want to return a value, don't declare it as void. If you declare it as void, don't return a value. It's really as simple as that. That's exactly kind of thing that makes me sad. Inviting rules in the language that exist for their own sake and then saying well, you don't like it, don't break the rules! -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
On Sat, Feb 14, 2015 at 6:03 AM, Xinchen Hui larue...@php.net wrote: Hey: On Sat, Feb 14, 2015 at 11:18 AM, Andrea Faulds a...@ajf.me wrote: Hi everyone, I’ve written a small RFC and patch to add a “void” return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. be honest, I think it's only part of the idea is implemented. which make it useless. in PHP, even if you don't return anything, NULL is returned implicitly. even if a function is declared return nothing(void). like: function a() : void {}; following codes still works: $b = a(); so, if you want a void return type, and if you want it to be a useful feature.. above expr should be invalid with an error a() return nothing so, I am -1 on this in complete RFC Hi Xinchen! While doing something like $b = a() where a() is a void function does not make sense usually (and e.g. C will generate a warning/error for this) in PHP there are some cases where you would want to use the return value of a void function. Namely those are cases where you aren't calling a specific function, but a callback that can return anything instead. E.g. consider something like a partial application helper: function bind($fn, ...$bindArgs) { return function(...$args) use($fn) { return $fn(...$bindArgs, ...$args); }; } Right now this would work no matter how $fn is declared. However if you disallow using the return value of void functions, you'd have to create an extra bindVoid() function which does exactly the same thing, just without the return. As such I don't think we can reasonably forbid using the return value of a void function. The utility of the void return type in PHP would be self-documenting function signatures. An IDE (or other static analyzer) would of course detect cases where the return value of a void function is used. Nikita
Re: [PHP-DEV] [RFC] Void Return Type
Hi! How ignoring values is a perfectly valid scenario? You are saying you're using return value for every function you're calling, always? Please. How many times you used return value of sort()? Every function with side effects can be used for its side effects, not for its return value. new paradigms. But we must provide features to make php relevant for a wider audience. And it is possible to do it without making it less easy This sounds like cargo cult, sorry - because other languages have void, we have to have void and then their users would come to us. That's exactly how cargo cult works - copying external appearances without considering underlying processes. In PHP, there's no meaning to void function except for self-enforcing documentation, and documentation should be properly done by other means and should not produce fatal errors. to use. We had the same discussion about OO when we developed 5.0, see where we are now. Stronger than ever. No, it's not like OO at all. OO is a huge conceptual framework with very wide use and it can help with developing code and making people more productive. Having void just helps with having void. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hi Robert, On 14 Feb 2015, at 21:23, Robert Stoll p...@tutteli.ch wrote: I think a void type for PHP would make sense but only if the return value of such a function cannot be used. Why? If the return value cannot be used, it prevents the function being used with any API that stores the return value of a callback. That’s not terribly nice. A void return value doesn’t need to enforce anything on the caller. PHP has always filled in missing values with NULLs, including return values, like other dynamic languages do here. Otherwise it is another reason for people to laugh at PHP and justifiably so, telling that a function does not return anything but return null is very inconsistent. It does implicitly return NULL, but NULL is a useless value, and it’s returned implicitly, rather than explicitly. I don’t think it’s really that ludicrous. I suggest to use one of the following behaviours: 1. declaring a function void does not return anything (hence is like echo to a certain agree) That makes it cease to be a function in the PHP sense. PHP always allows functions to be used in expressions. 2. declaring a function void does return a thing of type void (that would be similar to Unit in scala) We don’t need another form of NULL. Also, a thing of type void could be passed around, just as the unit type can be in other languages, so it wouldn’t do what you want it to. 3. instead of void a function can be declared to be of type null - almost the same behaviour as your RFC but without the inconsistency That seems like a strange solution. You’re requiring the function to always return a useless value. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
On Sat, Feb 14, 2015 at 01:03:44PM +0800, Xinchen Hui wrote: function a() : void {}; following codes still works: $b = a(); so, if you want a void return type, and if you want it to be a useful feature.. above expr should be invalid with an error a() return nothing +1 - my first thought. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Void Return Type
De : Andrea Faulds [mailto:a...@ajf.me] I’ve written a small RFC and patch to add a “void” return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. That's a nice addition and a beginning to distinguish void from null, as I imagine the function still returns null. Now, what about making void a real zval type ? It would open a lot of possibilities. Unlike null, conversions from void would raise an error. It would also be rejected as argument input type but could be used as an output type when arg is passed by ref, it could be the default type for return_value (huge BC break here) and so on... There's a need for a real 'no value' type different from null, as null has too many uses. If defined correctly, it can be a powerful addition. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Hey: On Sat, Feb 14, 2015 at 11:18 AM, Andrea Faulds a...@ajf.me wrote: Hi everyone, I’ve written a small RFC and patch to add a “void” return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. be honest, I think it's only part of the idea is implemented. which make it useless. in PHP, even if you don't return anything, NULL is returned implicitly. even if a function is declared return nothing(void). like: function a() : void {}; following codes still works: $b = a(); so, if you want a void return type, and if you want it to be a useful feature.. above expr should be invalid with an error a() return nothing so, I am -1 on this in complete RFC thanks Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
HI, On 14 February 2015 at 12:57, François Laupretre franc...@php.net wrote: De : Andrea Faulds [mailto:a...@ajf.me] I've written a small RFC and patch to add a void return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. That's a nice addition and a beginning to distinguish void from null, as I imagine the function still returns null. Now, what about making void a real zval type ? It would open a lot of possibilities. Unlike null, conversions from void would raise an error. It would also be rejected as argument input type but could be used as an output type when arg is passed by ref, it could be the default type for return_value (huge BC break here) and so on... There's a need for a real 'no value' type different from null, as null has too many uses. If defined correctly, it can be a powerful addition. What is the benefit of passing a void value around just for return type? and the rest of engine will have to take care of IS_VOID type, it seems doesn't worth it. François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] [RFC] Void Return Type
Hi! I’ve written a small RFC and patch to add a “void” return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. I'm not sure what it is useful for, exactly. I mean, the more fatal errors the merrier, but I fail to see what exactly use except having yet more cases when your code may break it provides. I mean, if you defined a void function, that means you're not using it return value anywhere. Then who cares what return statement says? If you _are_ using its return value, then a) why you declared it as void and b) how comes you expect return value from a function that is supposed to always return null? Additionally, this RFC gets inheritance wrong - having return from function that previously did not return anything is not a violation of contract, since there's no practical contract that can rely on function not returning anything (in fact, there's no way in PHP to even check that AFAIK). Summarily, this seems to me an exercise in strictness for the sake of strictness. There are languages that force people to abide by a lot of rules because their creators believe more rules is the same as better code, but PHP never was one of them and the fact there are so many people trying to make PHP that makes me sad. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Void Return Type
Do we really have to throw an catchable fatal error? the other return types make sense, why so strict? On 14 February 2015 at 11:18, Andrea Faulds a...@ajf.me wrote: Hi everyone, I've written a small RFC and patch to add a void return type: https://wiki.php.net/rfc/void_return_type Please have a read over it. I think this would be a simple, yet useful addition. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Reeze Xia http://reeze.cn