# [RFC] Nullable Types - Thread: https://externals.io/message/92273 - Original archive: https://news-web.php.net/php.internals/92273 - Started by Levi Morrison on 2016-04-14T03:42:25+00:00 - Messages: 25 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #92273 — Levi Morrison — 2016-04-14T03:42:25+00:00 URL: https://externals.io/message/92273#92273 As alluded to in an earlier email today[1] I am now moving the Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC proposes syntax for declaring a type to alternatively be null. There is a decision that needs to be made: does the question mark go before or after the type name? function (?Foo $foo); function (Foo? $foo); There are precedents in several languages for each position. Some relevant issues to where the question mark goes are noted in the RFC[3]. I look forward to a helpful and meaningful discussion! [1]: http://news.php.net/php.internals/92252 [2]: https://wiki.php.net/rfc/nullable_types [3]: https://wiki.php.net/rfc/nullable_types#position_of --- ## #92276 — Dmitry Stogov — 2016-04-14T07:50:12+00:00 URL: https://externals.io/message/92273#92276 · In reply to: #92273 > As alluded to in an earlier email today[1] I am now moving the > Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC > proposes syntax for declaring a type to alternatively be null. +1 The up to date implementation for return-type-hints may be found at https://github.com/php/php-src/pull/1851/files Implementation for argument-type-hints is really not a problem > > There is a decision that needs to be made: does the question mark go > before or after the type name? > > function (?Foo $foo); > function (Foo? $foo); > > There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3]. It's better to use ? position before the type, to reduce fragmentation with HHVM. Thanks. Dmitry. > > I look forward to a helpful and meaningful discussion! > > [1]: http://news.php.net/php.internals/92252 > [2]: https://wiki.php.net/rfc/nullable_types > [3]: https://wiki.php.net/rfc/nullable_types#position_of --- ## #92281 — Derick Rethans — 2016-04-14T09:00:32+00:00 URL: https://externals.io/message/92273#92281 · In reply to: #92273 > As alluded to in an earlier email today[1] I am now moving the > Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC > proposes syntax for declaring a type to alternatively be null. > > There is a decision that needs to be made: does the question mark go > before or after the type name? > > function (?Foo $foo); > function (Foo? $foo); > > There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3]. Please put it where HHVM puts it: in front of it. Other languages are less of an issue than a syntax that's already used in a somewhat PHP language. As to the rest of the RFC: LGTM! cheers, Derick --- ## #92290 — Davey Shafik — 2016-04-14T09:59:09+00:00 URL: https://externals.io/message/92273#92290 · In reply to: #92281 > > > > […] > > Please put it where HHVM puts it: in front of it. Other languages are > less of an issue than a syntax that's already used in a somewhat PHP > language. > > As to the rest of the RFC: LGTM! I much prefer the "Nullable Foo" (?Foo) to "Foo or Null" (Foo?). I find it easier to read. However, I am not a fan of introducing both this and the "Null" type for union types — this should be the only way to create nullable types. We already have too many things that are possible in more than one way. As it sits, this is purely syntactic sugar (when taken in tandem with union types) and [if] we agree that it is good, then let us just forgo the other syntax entirely. I'll add a little about that on the appropriate thread. - Davey --- ## #92292 — Matt Prelude — 2016-04-14T10:09:52+00:00 URL: https://externals.io/message/92273#92292 · In reply to: #92290 > > > > […] > > I much prefer the "Nullable Foo" (?Foo) to "Foo or Null" (Foo?). I find it > easier to read. > > However, I am not a fan of introducing both this and the "Null" type for > union types — this should be the only way to create nullable types. We > already have too many things that are possible in more than one way. > > As it sits, this is purely syntactic sugar (when taken in tandem with union > types) and [if] we agree that it is good, then let us just forgo the other > syntax entirely. I'll add a little about that on the appropriate thread. > > - Davey > Also agree, the "nullable foo" reads better and has the advantage of compatibility with HHVM. The easier we make it for people to switch interpreters (and develop software which works on both interpreters) the better for PHP as a whole. Also agree that we don't need null union types if we have nullable types. - Matt --- ## #92308 — Fleshgrinder — 2016-04-14T17:41:29+00:00 URL: https://externals.io/message/92273#92308 · In reply to: #92292 > As alluded to in an earlier email today[1] I am now moving the > Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC > proposes syntax for declaring a type to alternatively be null. > > There is a decision that needs to be made: does the question mark go > before or after the type name? > > function (?Foo $foo); > function (Foo? $foo); > > There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3]. > > I look forward to a helpful and meaningful discussion! > > [1]: http://news.php.net/php.internals/92252 > [2]: https://wiki.php.net/rfc/nullable_types > [3]: https://wiki.php.net/rfc/nullable_types#position_of > I have to agree with the question mark in front after reading the possible problems with the question mark as a suffix, the fact that HHVM already puts it in front, and the argument to read it as "nullable type" instead of "type or null". :) +1 -- Richard "Fleshgrinder" Fussenegger --- ## #92345 — Tom Worster — 2016-04-15T17:17:25+00:00 URL: https://externals.io/message/92273#92345 · In reply to: #92276 > The up to date implementation for return-type-hints may be found at > https://github.com/php/php-src/pull/1851/files Splendid! Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1]. Tom [1] https://wiki.php.net/rfc/nullable_returns --- ## #92347 — Dmitry Stogov — 2016-04-15T17:58:38+00:00 URL: https://externals.io/message/92273#92347 A week ago, I actually wrote my own RFC https://wiki.php.net/rfc/nullable_return_types but didn't push it for discussion in favor of Levi's nullable_type RFC (they are almost the same). I'm sure, union types bring too many conceptual and implementation questions, and I even don't speak abut intersections. Thanks. Dmitry. ________________________________________ From: Tom Worster Sent: Friday, April 15, 2016 20:17 To: Dmitry Stogov; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types > The up to date implementation for return-type-hints may be found at > https://github.com/php/php-src/pull/1851/files Splendid! Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1]. Tom [1] https://wiki.php.net/rfc/nullable_returns --- ## #92350 — Lester Caine — 2016-04-15T18:53:44+00:00 URL: https://externals.io/message/92273#92350 · In reply to: #92347 > I'm sure, union types bring too many conceptual and implementation questions, and I even don't speak abut intersections. The one problem I see with all of this is that it is reliant on every single variable being passed in when in early PHP5 days the preference was to move to hashes of data passed as arrays to open up flexibility. None of my record handling currently relies on having every 'parameter' formally defined, and elements of the record that are not passed in the hash are most definitely replaced by null valued elements allowing the DB engine to supply the relevant schema default unless it is replaced by additional variable in the data array. The idea of converting every record array into an object with multiple 'typed' variables seems to me to be a total overload to me, but if that is what people think is essential to make PHP 'safer' then that some of those variables are inherently 'null' or need to be switched to null if a change is required back to the schema default. 'Union' does not fit easily into this model? Documenting the content of a record hash via the docblock comments fits perfectly with this method working ... -- 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 --- ## #92361 — Tom Worster — 2016-04-16T01:54:38+00:00 URL: https://externals.io/message/92273#92361 · In reply to: #92347 > A week ago, I actually wrote my own RFC https://wiki.php.net/rfc/nullable_return_types You proposed the ?Something grammar. With ?: and ?? appearing in recent PHP and proposals for ??= if not ?:= and now this, I feel we're heading to regex hell :p Tom > but didn't push it for discussion in favor of Levi's nullable_type RFC (they are almost the same). --- ## #92365 — Lester Caine — 2016-04-16T09:24:44+00:00 URL: https://externals.io/message/92273#92365 · In reply to: #92273 > There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3]. Another discussion reference ... http://www.firebirdsql.org/manual/nullguide.html http://www.firebirdsql.org/manual/nullguide-check-constraints.html adds a little complexity to the validation 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 --- ## #92401 — Dmitry Stogov — 2016-04-18T08:59:22+00:00 URL: https://externals.io/message/92273#92401 The grammar is taken from HHVM. Using any other would make more mess. Thanks. Dmitry. --- ## #92415 — Lin Yo-An — 2016-04-18T16:24:32+00:00 URL: https://externals.io/message/92273#92415 · In reply to: #92401 > The grammar is taken from HHVM. > Using any other would make more mess. > I agree --- ## #92546 — guilhermeblanco@gmail.com — 2016-04-20T15:05:58+00:00 URL: https://externals.io/message/92273#92546 · In reply to: #92415 I read the RFC and I want to highlight why I'll vote -1 on it even before it goes to voting. IMHO, it looks backwards to what the language is progressing. The introduction of nullable type hint as a separate notation than a simple type hint makes it *very* hard to implement typed properties, factory methods and constructor verifications. Dmitry is even involved in the discussion of having IS_UNDEF until constructor ends, then enforcing type hinting at the end of constructor to trigger potential invalid instance state. It created a mess in the internal structure by creating a 3-state value: uninitialized, absent of value (null) and assigned value. All this problem would be solved by merging null into accepted value. So far the proposed solution there to take a wrong assumption to assume a default value based on type defined (like int = 0, string = '', etc), which are all potential valid values, leading to unpredictable behavior if a develop misses to assign a value to that property. Sure, people will say that now PHP will require a NullPointerException, PHP is turning into Java, or that I don't know what I'm talking about because they coded for Amiga and I don't (yes, I've seen that already in this mailing list). But the fact is that keeping control of 3-state flags are hard to maintain. Constructor verifications is actually a completely different subject that shouldn't be considered as part of typed properties, but for final properties (or whoever other keyword someone think is smarter because *reasons*). It's bad to bring this already to typed properties, specially because of its runtime performance impact. Now let's say we move forward with nullable type hint, ignore everything what I said and move forward. Congratulations, we just created a language inconsistency. Example: function foo(Bar $bar = null); Why now I have 2 ways to define a nullable value? Shouldn't this be changed into this: function foo(?Bar $bar); But of course, changing this would be a BC break and should be left for *reasons*. But accepting the absence of value (null) as a valid value, it would address the language inconsistency (the current support would be kept, so no BC break), and would solve a huge mess that typed properties patch currently needs to solve. Ah, and we don't continue into this path of madness where same thing have 144 different ways in different areas to be defined. Regards, On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An wrote: > > > > […] > I agree > -- Guilherme Blanco Lead Architect at E-Block --- ## #92556 — Dmitry Stogov — 2016-04-20T16:13:31+00:00 URL: https://externals.io/message/92273#92556 What we really miss now, is an ability to define nullable return types. https://wiki.php.net/rfc/nullable_return_types I don't care about the same notations for arguments (and everything else), because we already may use `NULL` default value. However usage of "?" for arguments also may make sense. Someone may like this, someone not. Thanks. Dmitry. --- ## #92558 — Thomas Bley — 2016-04-20T16:53:07+00:00 URL: https://externals.io/message/92273#92558 · In reply to: #92556 What do you think about default return values? e.g. function foo(): db_result = null { } function canLogin(): bool = false { } Regards Thomas Dmitry Stogov wrote on 20.04.2016 18:13: > What we really miss now, is an ability to define nullable return types. > > > https://wiki.php.net/rfc/nullable_return_types > > > I don't care about the same notations for arguments (and everything else), > because we already may use `NULL` default value. > > However usage of "?" for arguments also may make sense. Someone may like this, > someone not. > > > Thanks. Dmitry. > > ________________________________ > From: guilhermeblanco@gmail.com > Sent: Wednesday, April 20, 2016 18:05 > To: Lin Yo-An > Cc: Dmitry Stogov; Tom Worster; internals > Subject: Re: [PHP-DEV] [RFC] Nullable Types > > I read the RFC and I want to highlight why I'll vote -1 on it even before it > goes to voting. > > IMHO, it looks backwards to what the language is progressing. The introduction > of nullable type hint as a separate notation than a simple type hint makes it > *very* hard to implement typed properties, factory methods and constructor > verifications. > > Dmitry is even involved in the discussion of having IS_UNDEF until constructor > ends, then enforcing type hinting at the end of constructor to trigger > potential invalid instance state. It created a mess in the internal structure > by creating a 3-state value: uninitialized, absent of value (null) and assigned > value. All this problem would be solved by merging null into accepted value. > So far the proposed solution there to take a wrong assumption to assume a > default value based on type defined (like int = 0, string = '', etc), which are > all potential valid values, leading to unpredictable behavior if a develop > misses to assign a value to that property. > > Sure, people will say that now PHP will require a NullPointerException, PHP is > turning into Java, or that I don't know what I'm talking about because they > coded for Amiga and I don't (yes, I've seen that already in this mailing list). > But the fact is that keeping control of 3-state flags are hard to maintain. > > Constructor verifications is actually a completely different subject that > shouldn't be considered as part of typed properties, but for final properties > (or whoever other keyword someone think is smarter because *reasons*). It's bad > to bring this already to typed properties, specially because of its runtime > performance impact. > > Now let's say we move forward with nullable type hint, ignore everything what I > said and move forward. Congratulations, we just created a language > inconsistency. Example: > > function foo(Bar $bar = null); > > Why now I have 2 ways to define a nullable value? Shouldn't this be changed > into this: > > function foo(?Bar $bar); > > But of course, changing this would be a BC break and should be left for > *reasons*. But accepting the absence of value (null) as a valid value, it would > address the language inconsistency (the current support would be kept, so no BC > break), and would solve a huge mess that typed properties patch currently needs > to solve. Ah, and we don't continue into this path of madness where same thing > have 144 different ways in different areas to be defined. > > > Regards, > > On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An > > wrote: > On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov > > wrote: > > > […] > I agree > > > > -- > Guilherme Blanco > Lead Architect at E-Block --- ## #92560 — guilhermeblanco@gmail.com — 2016-04-20T17:41:16+00:00 URL: https://externals.io/message/92273#92560 · In reply to: #92556 PHP lacks of enterprise engineering over the language, and that is the problem. You're not resolving the holism in the language, but rather a specific part without consider the whole. Yes, it makes sense to support ?Foo for and only for return types, but what about everything else? What about future scope? Sure, future scope is unknown, but we do have scope that is currently being defined, you're even debating over it and it'll severely impacted by this small little support that we're adopting right now only for this specific case. The problem of not thinking in the language as a whole and just fixing small bits every time lead to the inconsistency hell we live today. So please, step back and look over that introducing this tiny language enhancement will impact final properties, typed properties and add a language inconsistency with already defined standard (instanced may be absent of value like in function parameters). If you don't think what I'm saying is true, look at return type hint and how you define parameter type hint. And with typed properties (as the patch currently stands), it will follow parameter type hint instead of return type hint. Regards, > What we really miss now, is an ability to define nullable return types. > > > https://wiki.php.net/rfc/nullable_return_types > > > I don't care about the same notations for arguments (and everything else), > because we already may use `NULL` default value. > > However usage of "?" for arguments also may make sense. Someone may like > this, someone not. > > > Thanks. Dmitry. > > ------------------------------ > *From:* guilhermeblanco@gmail.com > *Sent:* Wednesday, April 20, 2016 18:05 > *To:* Lin Yo-An > *Cc:* Dmitry Stogov; Tom Worster; internals > *Subject:* Re: [PHP-DEV] [RFC] Nullable Types > > I read the RFC and I want to highlight why I'll vote -1 on it even before > it goes to voting. > > IMHO, it looks backwards to what the language is progressing. The > introduction of nullable type hint as a separate notation than a simple > type hint makes it *very* hard to implement typed properties, factory > methods and constructor verifications. > > Dmitry is even involved in the discussion of having IS_UNDEF until > constructor ends, then enforcing type hinting at the end of constructor to > trigger potential invalid instance state. It created a mess in the internal > structure by creating a 3-state value: uninitialized, absent of value > (null) and assigned value. All this problem would be solved by merging null > into accepted value. > So far the proposed solution there to take a wrong assumption to assume a > default value based on type defined (like int = 0, string = '', etc), which > are all potential valid values, leading to unpredictable behavior if a > develop misses to assign a value to that property. > > Sure, people will say that now PHP will require a NullPointerException, > PHP is turning into Java, or that I don't know what I'm talking about > because they coded for Amiga and I don't (yes, I've seen that already in > this mailing list). But the fact is that keeping control of 3-state flags > are hard to maintain. > > Constructor verifications is actually a completely different subject that > shouldn't be considered as part of typed properties, but for final > properties (or whoever other keyword someone think is smarter because > *reasons*). It's bad to bring this already to typed properties, specially > because of its runtime performance impact. > > Now let's say we move forward with nullable type hint, ignore everything > what I said and move forward. Congratulations, we just created a language > inconsistency. Example: > > function foo(Bar $bar = null); > > Why now I have 2 ways to define a nullable value? Shouldn't this be > changed into this: > > function foo(?Bar $bar); > > But of course, changing this would be a BC break and should be left for > *reasons*. But accepting the absence of value (null) as a valid value, it > would address the language inconsistency (the current support would be > kept, so no BC break), and would solve a huge mess that typed properties > patch currently needs to solve. Ah, and we don't continue into this path of > madness where same thing have 144 different ways in different areas to be > defined. > > > Regards, > > On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An > wrote: > > > […] > > > > -- > Guilherme Blanco > Lead Architect at E-Block > -- Guilherme Blanco Lead Architect at E-Block --- ## #92561 — Jesse Schalken — 2016-04-20T17:55:53+00:00 URL: https://externals.io/message/92273#92561 · In reply to: #92273 I read the RFC and it all sounds good to me. I appreciate the care taken to ensure method compatibility rules are correct, a smooth interop with =null, and to consider impact on union types if added later (? just becomes sugar). I'm not sure if it's been mentioned or not, but the position of the ? has impact on the ability to add a foo[] shorthand for generic arrays. Namely, if the ? is at the start, then the syntax becomes ambiguous. string[]? (nullable array of strings) string?[] (array of nullable strings) ?string[] (ambiguous, need to consult precedence rules and/or use brackets) I'm not sure how HHVM/Hack deals with that, or if it even has the foo[] shorthand. On Thu, Apr 14, 2016 at 1:42 PM, Levi Morrison wrote: > As alluded to in an earlier email today[1] I am now moving the > Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC > proposes syntax for declaring a type to alternatively be null. > > There is a decision that needs to be made: does the question mark go > before or after the type name? > > function (?Foo $foo); > function (Foo? $foo); > > There are precedents in several languages for each position. Some > relevant issues to where the question mark goes are noted in the > RFC[3]. > > I look forward to a helpful and meaningful discussion! > > [1]: http://news.php.net/php.internals/92252 > [2]: https://wiki.php.net/rfc/nullable_types > [3]: https://wiki.php.net/rfc/nullable_types#position_of --- ## #92563 — Levi Morrison — 2016-04-20T18:28:17+00:00 URL: https://externals.io/message/92273#92563 · In reply to: #92561 > I read the RFC and it all sounds good to me. I appreciate the care taken to > ensure method compatibility rules are correct, a smooth interop with =null, > and to consider impact on union types if added later (? just becomes sugar). > > I'm not sure if it's been mentioned or not, but the position of the ? has > impact on the ability to add a foo[] shorthand for generic arrays. Namely, > if the ? is at the start, then the syntax becomes ambiguous. > > string[]? (nullable array of strings) > > string?[] (array of nullable strings) > > ?string[] (ambiguous, need to consult precedence rules and/or use brackets) > > > I'm not sure how HHVM/Hack deals with that, or if it even has the foo[] > shorthand. You would write `array`; Hack doesn't have a short-hand syntax. --- ## #92594 — fsb@thefsb.org — 2016-04-21T13:02:35+00:00 URL: https://externals.io/message/92273#92594 +1 to what Dmity wrote. I prefer not to have ?Something argument hints but I acknowledge that others want it. Tom From: Dmitry Stogov Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎13‎ ‎PM To: guilhermeblanco@gmail.com, Lin Yo-An Cc: Tom Worster, internals What we really miss now, is an ability to define nullable return types. https://wiki.php.net/rfc/nullable_return_types I don't care about the same notations for arguments (and everything else), because we already may use `NULL` default value. However usage of "?" for arguments also may make sense. Someone may like this, someone not. Thanks. Dmitry. From: guilhermeblanco@gmail.com Sent: Wednesday, April 20, 2016 18:05 To: Lin Yo-An Cc: Dmitry Stogov; Tom Worster; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types I read the RFC and I want to highlight why I'll vote -1 on it even before it goes to voting. IMHO, it looks backwards to what the language is progressing. The introduction of nullable type hint as a separate notation than a simple type hint makes it *very* hard to implement typed properties, factory methods and constructor verifications. Dmitry is even involved in the discussion of having IS_UNDEF until constructor ends, then enforcing type hinting at the end of constructor to trigger potential invalid instance state. It created a mess in the internal structure by creating a 3-state value: uninitialized, absent of value (null) and assigned value. All this problem would be solved by merging null into accepted value. So far the proposed solution there to take a wrong assumption to assume a default value based on type defined (like int = 0, string = '', etc), which are all potential valid values, leading to unpredictable behavior if a develop misses to assign a value to that property. Sure, people will say that now PHP will require a NullPointerException, PHP is turning into Java, or that I don't know what I'm talking about because they coded for Amiga and I don't (yes, I've seen that already in this mailing list). But the fact is that keeping control of 3-state flags are hard to maintain. Constructor verifications is actually a completely different subject that shouldn't be considered as part of typed properties, but for final properties (or whoever other keyword someone think is smarter because *reasons*). It's bad to bring this already to typed properties, specially because of its runtime performance impact. Now let's say we move forward with nullable type hint, ignore everything what I said and move forward. Congratulations, we just created a language inconsistency. Example: function foo(Bar $bar = null); Why now I have 2 ways to define a nullable value? Shouldn't this be changed into this: function foo(?Bar $bar); But of course, changing this would be a BC break and should be left for *reasons*. But accepting the absence of value (null) as a valid value, it would address the language inconsistency (the current support would be kept, so no BC break), and would solve a huge mess that typed properties patch currently needs to solve. Ah, and we don't continue into this path of madness where same thing have 144 different ways in different areas to be defined. Regards, > The grammar is taken from HHVM. > Using any other would make more mess. > I agree -- Guilherme Blanco Lead Architect at E-Block --- ## #92593 — fsb@thefsb.org — 2016-04-21T13:05:24+00:00 URL: https://externals.io/message/92273#92593 Hi Thomas, What is a default return declaration? Is this for branches within the function that do not lead to a return statement? Tom From: Thomas Bley Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎53‎ ‎PM To: guilhermeblanco@gmail.com, cornelius.howl@gmail.com, dmitry@zend.com Cc: fsb@thefsb.org, internals@lists.php.net What do you think about default return values? e.g. function foo(): db_result = null { } function canLogin(): bool = false { } --- ## #92599 — Thomas Bley — 2016-04-21T16:33:34+00:00 URL: https://externals.io/message/92273#92599 · In reply to: #92593 Hello Tom, with default return value I mean to return a certain value if nothing else is returned (similar to method parameters with a default value). example 1: declare(strict_types=0); function my_strpos(string $haystack, string $needle): int = false { return 42; // return 42 return false; // return false return true; // return 1 return; // return false } example 2: declare(strict_types=1); function my_strpos(string $haystack, string $needle): int = false { return 42; // return 42 return false; // return false return true; // fatal error return; // return false } Regards Thomas fsb@thefsb.org wrote on 21.04.2016 15:05: > Hi Thomas, > > > What is a default return declaration? Is this for branches within the function > that do not lead to a return statement? > > > Tom > > > > > > From: Thomas Bley > Sent: ‎Wednesday‎, ‎April‎ ‎20‎, ‎2016 ‎12‎:‎53‎ ‎PM > To: guilhermeblanco@gmail.com, cornelius.howl@gmail.com, dmitry@zend.com > Cc: fsb@thefsb.org, internals@lists.php.net > > > > > > What do you think about default return values? > > e.g. > > function foo(): db_result = null { > } > > function canLogin(): bool = false { > } --- ## #92605 — Fleshgrinder — 2016-04-21T19:33:02+00:00 URL: https://externals.io/message/92273#92605 · In reply to: #92599 > Hello Tom, > > with default return value I mean to return a certain value if nothing else is returned (similar to method parameters with a default value). > > example 1: > > declare(strict_types=0); > > function my_strpos(string $haystack, string $needle): int = false { > return 42; // return 42 > return false; // return false > return true; // return 1 > return; // return false > } > > example 2: > > declare(strict_types=1); > > function my_strpos(string $haystack, string $needle): int = false { > return 42; // return 42 > return false; // return false > return true; // fatal error > return; // return false > } > I definitely do not like the equal sign in there because it goes against all my mathematical knowledge; an int is false?!? Note that the same /would/ be possible with union types if given precedence: function fn(): int|false {} That being said, it is way too magic! A return without an argument is *void* and has to result in a `TypeError`. Really, start to think about the types as /checked annotations/ ... /** * @return int|false */ function fn() {} function fn(): int|false {} ... are equivalent and the former does not suddenly return *false* on its own and hell it shouldn't. -- Richard "Fleshgrinder" Fussenegger --- ## #92611 — Thomas Bley — 2016-04-21T21:47:20+00:00 URL: https://externals.io/message/92273#92611 · In reply to: #92605 > Note that the same /would/ be possible with union types if given precedence: > > function fn(): int|false {} false is currently not supported in the union_types rfc. Regards Thomas Fleshgrinder wrote on 21.04.2016 21:33: > > > […] > > I definitely do not like the equal sign in there because it goes against > all my mathematical knowledge; an int is false?!? > > Note that the same /would/ be possible with union types if given precedence: > > function fn(): int|false {} > > That being said, it is way too magic! A return without an argument is > *void* and has to result in a `TypeError`. Really, start to think about > the types as /checked annotations/ ... > > /** > * @return int|false > */ > function fn() {} > > function fn(): int|false {} > > ... are equivalent and the former does not suddenly return *false* on > its own and hell it shouldn't. > > -- > Richard "Fleshgrinder" Fussenegger --- ## #92694 — Tom Worster — 2016-04-24T15:18:21+00:00 URL: https://externals.io/message/92273#92694 · In reply to: #92599 Hi Thomas, Sorry for the delay. I was traveling last week. By convention `return;` in PHP is an early return for a function that returns nothing at all. I think it can be confusing when reading a function to look at a `return;` line and have to remember to look elsewhere to discover what that means. And it can mean something different in every function. I prefer to write functions that return only the declared type. In some cases I need to write functions that return only the declared type or null. That's the limit of what I think PHP 7.1 should provide. Hence, for me this has no attraction but it does introduce new ways to write bugs. So I am not enthusiastic. Tom >Hello Tom, > >with default return value I mean to return a certain value if nothing >else is returned (similar to method parameters with a default value). > >example 1: > >declare(strict_types=0); > >function my_strpos(string $haystack, string $needle): int = false { > return 42; // return 42 > return false; // return false > return true; // return 1 > return; // return false >} > >example 2: > >declare(strict_types=1); > >function my_strpos(string $haystack, string $needle): int = false { > return 42; // return 42 > return false; // return false > return true; // fatal error > return; // return false >} > >Regards >Thomas > > >fsb@thefsb.org wrote on 21.04.2016 15:05: > > > […]