Re: [PHP-DEV] [RFC] Nullable Types

[Jesse Schalken]

On Sun, Apr 24, 2016 at 2:58 AM, Levi Morrison  wrote:

> 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>. This is
important if you have a generic class Foo that uses Option internally
and Foo is instantiated as Foo (using string as an
example), causing an Option to occur inside Foo. If
Option meant string|null, the Option would become
string|null|null and the real "null" at runtime would become ambiguous.

Nonetheless, nesting is very rarely needed, but it is something to keep in
mind when using generics in combination with union with null for
nullability.



> 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

[Tom Worster]

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

[Quim Calpe]

On Sat, Apr 23, 2016 at 6:58 PM, Levi Morrison  wrote:

> 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

[Levi Morrison]

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.

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

[Quim Calpe]

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

Re: [PHP-DEV] [RFC] Nullable Types

[Fleshgrinder]

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

[Quim Calpe]

On Thu, Apr 21, 2016 at 9:52 PM, Fleshgrinder  wrote:

> 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

[Thomas Bley]

> 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

[Fleshgrinder]

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

[Fleshgrinder]

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

[Thomas Bley]

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

[fsb]

+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

[fsb]

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

[Lin Yo-An]

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

[Levi Morrison]

On Wed, Apr 20, 2016 at 11:55 AM, Jesse Schalken  wrote:
> 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

[Jesse Schalken]

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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Nullable Types

[guilhermebla...@gmail.com]

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

[Thomas Bley]

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

[Dmitry Stogov]

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

[guilhermebla...@gmail.com]

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:
>
> > 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

[Lin Yo-An]

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

Re: [PHP-DEV] [RFC] Nullable Types

[Dmitry Stogov]

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

[Björn Larsson]

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

[Lester Caine]

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

[Tom Worster]

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

[Lester Caine]

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

[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.

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

[Tom Worster]

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

[Fleshgrinder]

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

[Matt Prelude]

On 14/04/16 10:59, Davey Shafik wrote:

On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethans  wrote:


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

[Davey Shafik]

On Thu, Apr 14, 2016 at 2:00 AM, Derick Rethans  wrote:

> 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

[Derick Rethans]

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

[Dmitry Stogov]

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