Re: [PHP-DEV] [RFC] Nullable Types
On Sun, Apr 24, 2016 at 2:58 AM, Levi Morrisonwrote: > On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe wrote: > > Option is no better than a union type with null[1]. If a language > requires an option to be unwrapped then it can do the same with some > type or null. This is what Swift does. These things are exactly > equivalent. > I don't think that's strictly true. Option (or Maybe) types that must be unwrapped can usually be safely nested as Option
Re: [PHP-DEV] [RFC] Nullable Types
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 On 4/21/16, 12:33 PM, "Thomas Bley"wrote: >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 > > >f...@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: guilhermebla...@gmail.com, cornelius.h...@gmail.com, dmi...@zend.com >> Cc: f...@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 { >> } > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On Sat, Apr 23, 2016 at 6:58 PM, Levi Morrisonwrote: > On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe wrote: > > Hi Richard, > > > > On Sat, Apr 23, 2016 at 2:30 PM, Fleshgrinder > wrote: > > > >> On 4/22/2016 11:42 AM, Quim Calpe wrote: > >> > IMHO, the point of Optional types is the intention, if you get an > >> > Option from a method, you have to deal with a None branch. Of > course > >> > you can just unwrap and go on, but it's a developer decision to do > that, > >> > not an oversight as using a Foo|null (or ?Foo) as an object directly. > >> > > >> > >> IMOH, the point of ?T is the intention, if you get a null from a method, > >> you have to deal with a null branch. Of course you can just ignore it > >> and go on, but it's a developer decision to do that, not an oversight as > >> using a Option as an object directly. > >> > >> Sorry, but this works in both directions. The problem is not null, the > >> problem is that there is no system that warns you (e.g. a compiler) > >> about the missing null check. I think that Ceylon solved this problem > >> extremely nicely without the introduction of something special. > >> > > > > Of course, this works in both directions, but I see a value in Option > types: > > > > function getByEmail(string $email) : ?User {} > > $user = getByEmail("f...@bar.com"); > > echo $user->getName(); > > > > I neglect the nullable return but works at first , all fine... > > .. a week later... "Warning: Call to a member function getName() on null" > > > > With Option type: > > function getByEmail(string $email) : Option[User] {} > > $user = getByEmail("f...@bar.com"); > > echo $user->getName(); > > > > IDE could warn me and It crashes right away, an option type must be > > unwrapped so I get the "intention" immediately :) > > > > > >> > >> function fn(): ?T {} > >> > >> $x = fn(); > >> if (is $x T) {} > >> else {} > >> > >> Not doing as above is a compiler error in Ceylon. However, I already > >> wrote multiple times that there are already statical code analysis tools > >> available that can find exactly such things in your code. One just needs > >> to use them. > >> > > > > That's really nice > > > >> > >> -- > >> Richard "Fleshgrinder" Fussenegger > >> > >> > > Option types are nice, but I feel we are going a bit off-topic. Option > > types work better with other niceties like for comprehensions, pattern > > matching... And I don't see PHP going that route in the near future, and > > probably It's not okay for PHP to go that route... > > > > Nullable return types is a better fit for PHP, null has been in the > > language from the beginning, I agree here > > Option is no better than a union type with null[1]. If a language > requires an option to be unwrapped then it can do the same with some > type or null. This is what Swift does. These things are exactly > equivalent. > My point was about the developer receiving an Optional type, being less error-prone than a nullable type. Not a language advantage. > > However in PHP we do not have generics, which means a nullable type is > actually better because we can express the type that participates with > null. With an Option type we cannot. > Yes, I was talking generically here, Option Types without generics-like behaviour are a lot less useful Nullable return types is indeed a better fit for PHP as I said [1] At least with the behaviors here. If Option is a Traverable that > returns 0 or 1 items then we can use that behavior to our advantage. > Of course, we lose the ability to express the underlying option type. >
Re: [PHP-DEV] [RFC] Nullable Types
On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpewrote: > Hi Richard, > > On Sat, Apr 23, 2016 at 2:30 PM, Fleshgrinder wrote: > >> On 4/22/2016 11:42 AM, Quim Calpe wrote: >> > IMHO, the point of Optional types is the intention, if you get an >> > Option from a method, you have to deal with a None branch. Of course >> > you can just unwrap and go on, but it's a developer decision to do that, >> > not an oversight as using a Foo|null (or ?Foo) as an object directly. >> > >> >> IMOH, the point of ?T is the intention, if you get a null from a method, >> you have to deal with a null branch. Of course you can just ignore it >> and go on, but it's a developer decision to do that, not an oversight as >> using a Option as an object directly. >> >> Sorry, but this works in both directions. The problem is not null, the >> problem is that there is no system that warns you (e.g. a compiler) >> about the missing null check. I think that Ceylon solved this problem >> extremely nicely without the introduction of something special. >> > > Of course, this works in both directions, but I see a value in Option types: > > function getByEmail(string $email) : ?User {} > $user = getByEmail("f...@bar.com"); > echo $user->getName(); > > I neglect the nullable return but works at first , all fine... > .. a week later... "Warning: Call to a member function getName() on null" > > With Option type: > function getByEmail(string $email) : Option[User] {} > $user = getByEmail("f...@bar.com"); > echo $user->getName(); > > IDE could warn me and It crashes right away, an option type must be > unwrapped so I get the "intention" immediately :) > > >> >> function fn(): ?T {} >> >> $x = fn(); >> if (is $x T) {} >> else {} >> >> Not doing as above is a compiler error in Ceylon. However, I already >> wrote multiple times that there are already statical code analysis tools >> available that can find exactly such things in your code. One just needs >> to use them. >> > > That's really nice > >> >> -- >> Richard "Fleshgrinder" Fussenegger >> >> > Option types are nice, but I feel we are going a bit off-topic. Option > types work better with other niceties like for comprehensions, pattern > matching... And I don't see PHP going that route in the near future, and > probably It's not okay for PHP to go that route... > > Nullable return types is a better fit for PHP, null has been in the > language from the beginning, I agree here Option is no better than a union type with null[1]. If a language requires an option to be unwrapped then it can do the same with some type or null. This is what Swift does. These things are exactly equivalent. However in PHP we do not have generics, which means a nullable type is actually better because we can express the type that participates with null. With an Option type we cannot. [1] At least with the behaviors here. If Option is a Traverable that returns 0 or 1 items then we can use that behavior to our advantage. Of course, we lose the ability to express the underlying option type. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
Hi Richard, On Sat, Apr 23, 2016 at 2:30 PM, Fleshgrinderwrote: > On 4/22/2016 11:42 AM, Quim Calpe wrote: > > IMHO, the point of Optional types is the intention, if you get an > > Option from a method, you have to deal with a None branch. Of course > > you can just unwrap and go on, but it's a developer decision to do that, > > not an oversight as using a Foo|null (or ?Foo) as an object directly. > > > > IMOH, the point of ?T is the intention, if you get a null from a method, > you have to deal with a null branch. Of course you can just ignore it > and go on, but it's a developer decision to do that, not an oversight as > using a Option as an object directly. > > Sorry, but this works in both directions. The problem is not null, the > problem is that there is no system that warns you (e.g. a compiler) > about the missing null check. I think that Ceylon solved this problem > extremely nicely without the introduction of something special. > Of course, this works in both directions, but I see a value in Option types: function getByEmail(string $email) : ?User {} $user = getByEmail("f...@bar.com"); echo $user->getName(); I neglect the nullable return but works at first , all fine... .. a week later... "Warning: Call to a member function getName() on null" With Option type: function getByEmail(string $email) : Option[User] {} $user = getByEmail("f...@bar.com"); echo $user->getName(); IDE could warn me and It crashes right away, an option type must be unwrapped so I get the "intention" immediately :) > > function fn(): ?T {} > > $x = fn(); > if (is $x T) {} > else {} > > Not doing as above is a compiler error in Ceylon. However, I already > wrote multiple times that there are already statical code analysis tools > available that can find exactly such things in your code. One just needs > to use them. > That's really nice > > -- > Richard "Fleshgrinder" Fussenegger > > Option types are nice, but I feel we are going a bit off-topic. Option types work better with other niceties like for comprehensions, pattern matching... And I don't see PHP going that route in the near future, and probably It's not okay for PHP to go that route... Nullable return types is a better fit for PHP, null has been in the language from the beginning, I agree here
Re: [PHP-DEV] [RFC] Nullable Types
On 4/22/2016 11:42 AM, Quim Calpe wrote: > IMHO, the point of Optional types is the intention, if you get an > Option from a method, you have to deal with a None branch. Of course > you can just unwrap and go on, but it's a developer decision to do that, > not an oversight as using a Foo|null (or ?Foo) as an object directly. > IMOH, the point of ?T is the intention, if you get a null from a method, you have to deal with a null branch. Of course you can just ignore it and go on, but it's a developer decision to do that, not an oversight as using a Option as an object directly. Sorry, but this works in both directions. The problem is not null, the problem is that there is no system that warns you (e.g. a compiler) about the missing null check. I think that Ceylon solved this problem extremely nicely without the introduction of something special. function fn(): ?T {} $x = fn(); if (is $x T) {} else {} Not doing as above is a compiler error in Ceylon. However, I already wrote multiple times that there are already statical code analysis tools available that can find exactly such things in your code. One just needs to use them. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Nullable Types
On Thu, Apr 21, 2016 at 9:52 PM, Fleshgrinderwrote: > On 4/21/2016 1:00 PM, Lin Yo-An wrote: > > I think this is not to make PHP like Java, and it totally makes sense - > > Nullable should be a type of a type instead of a state. In Haskell it's > > named Maybe or Option, and It's better than NullPointerException. > > > > Here is a discussion from Haskell community: > > https://mail.haskell.org/pipermail/haskell-cafe/2011-April/091269.html > > > > Why is it /better/? > > final class None {} > > final class Some { > > public $value; > > public function __construct($value) { > $this->value = $value; > } > > } > > final class Maybe { > > private static $none; > > private $value; > > private function __construct($value) { > $this->value = $value; > } > > public static function NOTHING() { > if (self::$nothing === null) { > self::$nothing = new Nothing(); > } > return new static(self::$nothing); > } > > public static function SOME($value) { > return new static(new Some($value)); > } > > public function hasSome(): bool { > return $this->value !== static::$none; > } > > public function isNone(): bool { > return $this->value === static::$none; > } > > public function unwrap() { > if ($this->value === static::$none) { > trigger_error('NullPointerException', E_USER_ERROR); > } > return $this->value->value; > } > > } > > // > > function f1(): Option {} > > $x = f1(); > if ($x->hasSome()) { > echo $x->unwrap(); // 42 > } > > $x = f1(); > if ($x->isNone()) { > echo -1; > } > > echo f1()->unwrap(); // error: NullPointerException :P > > // > > function f2(): ?int {} > > $y = f2(); > if (isset($y)) { > echo $y; // 42 > } > > $y = f2(); > if ($y === null) { > echo -1; > } > > echo f2(); // null > > You can easily build your own Option or Maybe and add the additional > bookkeeping to your runtime but it will not make your program more > secure or anything. It just adds more method calls and makes it more > verbose. > > You can already use static code analyzers to detect if null is being > ignored in your code, however, right now they mainly have to rely on > PhpDoc that is often not properly documented. Adding an explicit syntax > to PHP for documentation would make PhpDoc obsolete and allow static > code analyzers to perform their job better and PHP to error out during > runtime if something else is being returned. > > Honestly, null is not our problem. Every language has its null, just > because they wrap it or rename it does not make null suddenly vanish > from the universe. :P > > -- > Richard "Fleshgrinder" Fussenegger > > IMHO, the point of Optional types is the intention, if you get an Option from a method, you have to deal with a None branch. Of course you can just unwrap and go on, but it's a developer decision to do that, not an oversight as using a Foo|null (or ?Foo) as an object directly.
Re: [PHP-DEV] [RFC] Nullable Types
> 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: > On 4/21/2016 6:33 PM, Thomas Bley wrote: >> 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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On 4/21/2016 1:00 PM, Lin Yo-An wrote: > I think this is not to make PHP like Java, and it totally makes sense - > Nullable should be a type of a type instead of a state. In Haskell it's > named Maybe or Option, and It's better than NullPointerException. > > Here is a discussion from Haskell community: > https://mail.haskell.org/pipermail/haskell-cafe/2011-April/091269.html > Why is it /better/? final class None {} final class Some { public $value; public function __construct($value) { $this->value = $value; } } final class Maybe { private static $none; private $value; private function __construct($value) { $this->value = $value; } public static function NOTHING() { if (self::$nothing === null) { self::$nothing = new Nothing(); } return new static(self::$nothing); } public static function SOME($value) { return new static(new Some($value)); } public function hasSome(): bool { return $this->value !== static::$none; } public function isNone(): bool { return $this->value === static::$none; } public function unwrap() { if ($this->value === static::$none) { trigger_error('NullPointerException', E_USER_ERROR); } return $this->value->value; } } // function f1(): Option {} $x = f1(); if ($x->hasSome()) { echo $x->unwrap(); // 42 } $x = f1(); if ($x->isNone()) { echo -1; } echo f1()->unwrap(); // error: NullPointerException :P // function f2(): ?int {} $y = f2(); if (isset($y)) { echo $y; // 42 } $y = f2(); if ($y === null) { echo -1; } echo f2(); // null You can easily build your own Option or Maybe and add the additional bookkeeping to your runtime but it will not make your program more secure or anything. It just adds more method calls and makes it more verbose. You can already use static code analyzers to detect if null is being ignored in your code, however, right now they mainly have to rely on PhpDoc that is often not properly documented. Adding an explicit syntax to PHP for documentation would make PhpDoc obsolete and allow static code analyzers to perform their job better and PHP to error out during runtime if something else is being returned. Honestly, null is not our problem. Every language has its null, just because they wrap it or rename it does not make null suddenly vanish from the universe. :P -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Nullable Types
On 4/21/2016 6:33 PM, Thomas Bley wrote: > 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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Nullable Types
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 f...@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: guilhermebla...@gmail.com, cornelius.h...@gmail.com, dmi...@zend.com > Cc: f...@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 { > } -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
+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: guilhermebla...@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: guilhermebla...@gmail.com <guilhermebla...@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 <cornelius.h...@gmail.com> wrote: On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmi...@zend.com> wrote: > The grammar is taken from HHVM. > Using any other would make more mess. > I agree -- Guilherme Blanco Lead Architect at E-Block
Re: [PHP-DEV] [RFC] Nullable Types
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: guilhermebla...@gmail.com, cornelius.h...@gmail.com, dmi...@zend.com Cc: f...@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 { }
Re: [PHP-DEV] [RFC] Nullable Types
On Wed, Apr 20, 2016 at 11:05 PM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > > 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. > I think this is not to make PHP like Java, and it totally makes sense - Nullable should be a type of a type instead of a state. In Haskell it's named Maybe or Option, and It's better than NullPointerException. Here is a discussion from Haskell community: https://mail.haskell.org/pipermail/haskell-cafe/2011-April/091269.html -- Best Regards, Yo-An Lin
Re: [PHP-DEV] [RFC] Nullable Types
On Wed, Apr 20, 2016 at 11:55 AM, Jesse Schalkenwrote: > 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
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 Morrisonwrote: > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Nullable Types
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, On Wed, Apr 20, 2016 at 12:13 PM, Dmitry Stogov <dmi...@zend.com> wrote: > 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:* guilhermebla...@gmail.com <guilhermebla...@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 <cornelius.h...@gmail.com> > wrote: > >> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmi...@zend.com> wrote: >> >> > The grammar is taken from HHVM. >> > Using any other would make more mess. >> > >> I agree >> > > > > -- > Guilherme Blanco > Lead Architect at E-Block > -- Guilherme Blanco Lead Architect at E-Block
Re: [PHP-DEV] [RFC] Nullable Types
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: guilhermebla...@gmail.com <guilhermebla...@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 > <cornelius.h...@gmail.com<mailto:cornelius.h...@gmail.com>> wrote: > On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov > <dmi...@zend.com<mailto:dmi...@zend.com>> wrote: > >> The grammar is taken from HHVM. >> Using any other would make more mess. >> > I agree > > > > -- > Guilherme Blanco > Lead Architect at E-Block > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
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: guilhermebla...@gmail.com <guilhermebla...@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 <cornelius.h...@gmail.com<mailto:cornelius.h...@gmail.com>> wrote: On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmi...@zend.com<mailto:dmi...@zend.com>> wrote: > The grammar is taken from HHVM. > Using any other would make more mess. > I agree -- Guilherme Blanco Lead Architect at E-Block
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-Anwrote: > On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov wrote: > > > The grammar is taken from HHVM. > > Using any other would make more mess. > > > I agree > -- Guilherme Blanco Lead Architect at E-Block
Re: [PHP-DEV] [RFC] Nullable Types
On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogovwrote: > The grammar is taken from HHVM. > Using any other would make more mess. > I agree
Re: [PHP-DEV] [RFC] Nullable Types
The grammar is taken from HHVM. Using any other would make more mess. Thanks. Dmitry. From: Tom Worster <f...@thefsb.org> Sent: Saturday, April 16, 2016 04:54 To: Dmitry Stogov; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types On 4/15/16 1:58 PM, Dmitry Stogov wrote: > 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). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
Den 2016-04-15 kl. 19:58, skrev Dmitry Stogov: 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. Reading this together with Levi's RFC and it gives a very clear picture on the proposed feature. Definitely a +1. Hope that part of the text in this RFC can be lifted into Levi's RFC. E.g. the binary tree example gives a good motivation / UC etc. Regards //Björn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On 14/04/16 04:42, Levi Morrison wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On 4/15/16 1:58 PM, Dmitry Stogov wrote: 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). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On 15/04/16 18:58, Dmitry Stogov wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
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 <f...@thefsb.org> Sent: Friday, April 15, 2016 20:17 To: Dmitry Stogov; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types On 4/14/16 3:50 AM, Dmitry Stogov wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On 4/14/16 3:50 AM, Dmitry Stogov wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On 4/14/2016 5:42 AM, 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 > 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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Nullable Types
On 14/04/16 10:59, Davey Shafik wrote: On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethanswrote: On Wed, 13 Apr 2016, 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]. 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethanswrote: > On Wed, 13 Apr 2016, 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]. > > 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
Re: [PHP-DEV] [RFC] Nullable Types
On Wed, 13 Apr 2016, 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]. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Types
On 04/14/2016 06:42 AM, 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. +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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Nullable Types
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php