Re: [PHP-DEV] [RFC] $this return type

[Nicolas Grekas]

Hi Nikita

Hi internals,
>
> I'd like to pick up a loose thread from the future scope of the
> https://wiki.php.net/rfc/static_return_type RFC, the $this return type for
> fluent APIs:
>
> https://wiki.php.net/rfc/this_return_type
>
> I have some reservations about this (which basically come down to $this not
> being a proper "type", so should it be in the type system?) but I can see
> the practical usefulness, so I think it's worth discussing this.
>

Thank you so much for the RFC. I'm really looking forward to being able to
use $this as a return type.

> On a dataset of 2k composer packages, @return $this occurs 29k times,
while @return static is used 38k times

This is really good to know. It makes it pretty clear to me that being able
to declare $this as a return value would be valuable to many projects!

As far as my experience is concerned, I tried switching from the `@return
$this` annotation to `function (): static`, which is the closest
approximation currently supported by the engine, when I realized that this
would loosen the semantics of the corresponding interfaces and kinda force
ppl to deal with the return value while this doesn't make sense in
fluent-style APIs. I therefore kept the annotation in place and I'm now
looking forward to being able to write this declaration using native syntax
- with the added benefit of having it enforced by the engine.

About the syntax, I think the one proposed in the RFC is crystal clear.
I've been used to seeing the "$" symbol when reading `@return $this`, and
this just makes sense, past the first surprise. I also think that using
"this" (without the dollar) could too easily be confused with something
that means our "static" (esp. considering that TypeScript uses "this" in
place of our "static".)

I'm reading in responses that $this is not a type, but I fail to understand
how that makes it an argument against the RFC. Neither false is a type, and
null is both a type and a value. Yet we have them because they provide
clear added value. Having $this could benefit 29k times the top 2k
packages. It doesn't look like a niche use case!

As you might have understood, I support the RFC and would vote for it as is
personally!

Nicolas

Re: [PHP-DEV] [RFC] $this return type

[Ben Ramsey]

> On Sep 9, 2021, at 09:47, Mike Schinkel  wrote:
> 
>> On Sep 9, 2021, at 10:26 AM, Flávio Heleno  wrote:
>> 
>> On Tue, Sep 7, 2021 at 10:27 AM Sebastian Bergmann 
>> wrote:
>> 
>>> Am 07.09.2021 um 12:28 schrieb Nikita Popov:
 I have some reservations about this (which basically come down to $this
>>> not
 being a proper "type", so should it be in the type system?) but I can see
 the practical usefulness, so I think it's worth discussing this.
>>> 
>>> I am not conviced that there is enough value in this to introduce syntax
>>> for it, but if at all, then please not "$this" as the name for a type.
>>> 
>>> Off the top of my head, I think that "same" could make sense.
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: https://www.php.net/unsub.php
>>> 
>>> 
>> Hi all,
>> 
>> I'm sorry if I'm being naive, or simply put dumb, but the main difference
>> that we're trying
>> to achieve with having "$this" (or variations of it) as a valid return type
>> as opposed to simply
>> using "self" is to ensure that the underlying code is actually doing a
>> "return $this" rather
>> than returning any other valid "self" instance (such as "return new
>> self();")?
> 
> So a *mutable* fluent style vs. an *immutable* fluent style?
> 
> -Mike


For clarity, in comparing to `self` and `static`…


`self`
:   the return value must be an instance of the same class that sets
this type declaration


`static`
:   the return value must be an instance of the same class that calls
the method with this type declaration


`$this`
:   the return value must be the same instance as the instance that
calls the method with this type declaration


Cheers,
Ben




signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] $this return type

[Mike Schinkel]

> On Sep 9, 2021, at 10:26 AM, Flávio Heleno  wrote:
> 
> On Tue, Sep 7, 2021 at 10:27 AM Sebastian Bergmann 
> wrote:
> 
>> Am 07.09.2021 um 12:28 schrieb Nikita Popov:
>>> I have some reservations about this (which basically come down to $this
>> not
>>> being a proper "type", so should it be in the type system?) but I can see
>>> the practical usefulness, so I think it's worth discussing this.
>> 
>> I am not conviced that there is enough value in this to introduce syntax
>> for it, but if at all, then please not "$this" as the name for a type.
>> 
>> Off the top of my head, I think that "same" could make sense.
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>> 
>> 
> Hi all,
> 
> I'm sorry if I'm being naive, or simply put dumb, but the main difference
> that we're trying
> to achieve with having "$this" (or variations of it) as a valid return type
> as opposed to simply
> using "self" is to ensure that the underlying code is actually doing a
> "return $this" rather
> than returning any other valid "self" instance (such as "return new
> self();")?

So a *mutable* fluent style vs. an *immutable* fluent style?

-Mike

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] $this return type

[Flávio Heleno]

On Tue, Sep 7, 2021 at 10:27 AM Sebastian Bergmann 
wrote:

> Am 07.09.2021 um 12:28 schrieb Nikita Popov:
> > I have some reservations about this (which basically come down to $this
> not
> > being a proper "type", so should it be in the type system?) but I can see
> > the practical usefulness, so I think it's worth discussing this.
>
> I am not conviced that there is enough value in this to introduce syntax
> for it, but if at all, then please not "$this" as the name for a type.
>
> Off the top of my head, I think that "same" could make sense.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Hi all,

I'm sorry if I'm being naive, or simply put dumb, but the main difference
that we're trying
to achieve with having "$this" (or variations of it) as a valid return type
as opposed to simply
using "self" is to ensure that the underlying code is actually doing a
"return $this" rather
than returning any other valid "self" instance (such as "return new
self();")?

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] [RFC] $this return type

[Sebastian Bergmann]

Am 07.09.2021 um 12:28 schrieb Nikita Popov:

I have some reservations about this (which basically come down to $this not
being a proper "type", so should it be in the type system?) but I can see
the practical usefulness, so I think it's worth discussing this.


I am not conviced that there is enough value in this to introduce syntax 
for it, but if at all, then please not "$this" as the name for a type.


Off the top of my head, I think that "same" could make sense.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] $this return type

[Christoph M. Becker]

On 07.09.2021 at 15:02, Andreas Heigl wrote:

> On 07.09.21 12:28, Nikita Popov wrote:
>
>> I'd like to pick up a loose thread from the future scope of the
>> https://wiki.php.net/rfc/static_return_type RFC, the $this return type
>> for
>> fluent APIs:
>>
>> https://wiki.php.net/rfc/this_return_type
>>
>> I have some reservations about this (which basically come down to
>> $this not
>> being a proper "type", so should it be in the type system?) but I can see
>> the practical usefulness, so I think it's worth discussing this.
>
> If we allow a $this (let's keep the actual naming out for the moment) as
> a returntype to clarify that it has to be the same instance that is
> returned, I would also either expect that the returntype 'self' does
> explicitly *not* allow the same instance to be returned. As that would
> be a huge BC break I would on the other hand also think that we should
> implement a returntype "!$this" to explicitly state that the contract
> here returns *not*  the current instance but a new one. That way a lot
> of immutable contracts could be made more clear.
>
> What'S your or others idea regarding that?

In my opinion, we should not muddy the waters here.  $this is not a type.

Instead we should consider to head for a more general solution, namely
suporting post-conditions, i.e. assertions which are part of the
function/method signature.  But that would certainly be the topic of
another RFC.

Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] $this return type

[Andreas Heigl]

Hey Nikita

On 07.09.21 12:28, Nikita Popov wrote:

Hi internals,

I'd like to pick up a loose thread from the future scope of the
https://wiki.php.net/rfc/static_return_type RFC, the $this return type for
fluent APIs:

https://wiki.php.net/rfc/this_return_type

I have some reservations about this (which basically come down to $this not
being a proper "type", so should it be in the type system?) but I can see
the practical usefulness, so I think it's worth discussing this.

Regards,
Nikita


If we allow a $this (let's keep the actual naming out for the moment) as 
a returntype to clarify that it has to be the same instance that is 
returned, I would also either expect that the returntype 'self' does 
explicitly *not* allow the same instance to be returned. As that would 
be a huge BC break I would on the other hand also think that we should 
implement a returntype "!$this" to explicitly state that the contract 
here returns *not*  the current instance but a new one. That way a lot 
of immutable contracts could be made more clear.


What'S your or others idea regarding that?

Cheers

Andreas
--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+


OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] $this return type

[Michał Marcin Brzuchalski]

Hi Nikita,

wt., 7 wrz 2021 o 12:29 Nikita Popov  napisał(a):

> Hi internals,
>
> I'd like to pick up a loose thread from the future scope of the
> https://wiki.php.net/rfc/static_return_type RFC, the $this return type for
> fluent APIs:
>
> https://wiki.php.net/rfc/this_return_type
>
> I have some reservations about this (which basically come down to $this not
> being a proper "type", so should it be in the type system?) but I can see
> the practical usefulness, so I think it's worth discussing this.


If the aim of $this return type is to force and check the return $this why
would we still need/require return statement to be obligatory?
Does that make sense to assume at the end of function flow the return
$this; statement to be present by default if the return type is not an
union etc.?

Cheers,
--
Michał Marcin Brzuchalski

[PHP-DEV] [RFC] $this return type

[Nikita Popov]

Hi internals,

I'd like to pick up a loose thread from the future scope of the
https://wiki.php.net/rfc/static_return_type RFC, the $this return type for
fluent APIs:

https://wiki.php.net/rfc/this_return_type

I have some reservations about this (which basically come down to $this not
being a proper "type", so should it be in the type system?) but I can see
the practical usefulness, so I think it's worth discussing this.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Static return type

[Guilliam Xavier]

Hi,

After reading all the thread:

I'm +1 for `: static` as proposed by this RFC.

I'm also +1 for `: $this`, preferably also in PHP 8.0, but that could
be a separate RFC:
- I like the idea to check it at compile time (like `: void`), i.e.
that all the return points of the method be syntactically `return
$this;` (maybe also allow `return $this->otherMethod(/*...*/);` where
the forwarded method is itself declared `: $this`).
- Regarding covariance, `$this` should probably be treated like a
"subtype" of `static`.
- I don't like the idea of making an implicit `return $this;` in
addition to the check.

I'm -1 for `: fluent` or `fluent function` as an alternative to `: $this`.

I'm -0.5 for `: new` / `: clone`.

About "what comes out is the same type as what goes in", I would wait
for generics.

-- 
Guilliam Xavier

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Static return type

[Mike Schinkel]

> On Jan 10, 2020, at 1:19 PM, Andreas Hennings  wrote:
> 
> This would work, but:
> ": $this". With fluent + static I would have to look in two places.

How about :fluent?   

This would indicate both a type and a further constraint meaning $this.

Something to consider...?

-Mike

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Static return type

[Andreas Hennings]

On Thu, 9 Jan 2020 at 20:53, Dik Takken  wrote:

> On 09-01-2020 17:52, Andreas Hennings wrote:
> > On Thu, 9 Jan 2020 at 16:31, Nikita Popov  wrote:
> >
> >> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins 
> >> wrote:
> >>
> >> An argument could be made that $this does also specify a certain
> contract
> >> to the caller: That the API may be used fluently or not without change
> in
> >> functionality. That is
> >>
> >> $foo->setBar();
> >> $foo->setBaz();
> >>
> >> must be strictly equivalent to
> >>
> >> $foo
> >>->setBar()
> >>->setBaz()
> >> ;
> >>
> >> The same is not the case for a plain "static" type. In fact, I think
> that
> >> for all other uses of "static" outside of fluent interfaces, not using
> the
> >> return value would be a programming error.
> >>
> >> But still, this kind of contract is not a type-system contract, and I'm
> not
> >> sure it's a good idea to mix other types of API contracts into the type
> >> system in this fashion.
> >>
> >
> > We currently don't have another "system" where this kind of info could be
> > specified.
>
> How about:
>
>   public fluent function doWhatever(): static
>
> Perhaps this could be introduced at some point in the future to enforce
> returning $this.
>

This would work, but:
- The ": static" would be redundant if the method is fluid.
- I still would find it more natural to look into the return hint and find
": $this". With fluent + static I would have to look in two places.

But I was thinking something else related to the ": $this" (or "fluent").
If we already annotate a method as fluent, then the actual "return $this;"
statement is redundant as well.
We _could_ make this implicit, so you no longer have to write "return
$this;".
Not sure if that's a good idea, and definitely not in scope of the ":
static" proposal. But I think it is useful to have an idea where we want to
go with this.




>
> > And in this case, $this also implies static, so if we would use whichever
> > other system to specify $this, the type hint "static" would become
> > redundant.
> >
> > "@return $this" is common in phpdoc (*) since a while, and so far I have
> > not seen any problems with it.
> >
> > If we ask "where does this lead?", one natural next step might be to
> > specifically say that the return type is the same type, but NOT $this.
> > So, a promise that we really get a new object which we can modify without
> > changing the original object.
> >
> > I don't know how we would express this. Perhaps ": clone", but this would
> > be too specific imo, because whether it is a clone is an implementation
> > detail.
>
> Maybe ": new" ?
>

To me this would not imply that this has to be the same type..

Either way, I think there is no strong enough reason to introduce a syntax
for this case.
It would be mostly for wither methods, and these can safely return the
original object if the entire thing is designed as immutable.


>
> Regards,
> Dik Takken
>

Re: [PHP-DEV] [RFC] Static return type

[Andrew Johnstone]

Sent from my iPhone

> On 9 Jan 2020, at 15:06, Rowan Tommins  wrote:
> 
> On Thu, 9 Jan 2020 at 14:23, Andreas Hennings  wrote:
> 
>>> However, $this is not a real type, and it is unclear what the advantage
>> of specifying $this rather than static would be from a type system level
>> perspective.
>> 
>> Perhaps not from a "type system level", but from a more broad "enforced
>> contract" level.
>> E.g. IDEs or code inspection tools can warn if a method will not return
>> $this.
>> This also means recursive calls also need to return $this instead of
>> static.
>> 
>> class C {
>>  function foo(): static {
>>return clone $this;
>>  }
>>  function bar(): $this {
>>return $this->foo();  // IDE can complain.
>>  }
>> }
>> 
> 
> 
> I think there are two different purposes for annotating return types:
> 
> 1) Contracts that tell the caller what values they should expect when
> calling the function.
> 2) Constraints on the implementation which don't affect the caller, but
> allow the author to catch certain bugs.
> 
> The primary purpose, in my mind, is (1), with (2) generally coming as a
> side-effect: if your contract is to return an int, then tools can warn you
> when you don't.
> 
> All concrete types can be seen this way: scalars, classes, and pseudo-types
> like "iterable" are all contracts that calling code can rely on. "self",
> "parent", and "static" fit into that list fine, because they're ultimately
> specifying a class name.
> 
> The special "void" keyword doesn't actually make sense as a contract given
> PHP's calling convention - as far as the calling code's concerned, it's
> equivalent to "null". So it exists only for purpose (2), constraining the
> implementation for the benefit of the function's author.
> 
> $this would fit into the same category - as far as calling code is
> concerned it is equivalent to "static", unless they're doing something very
> specific with object identity. This makes it an odd constraint on
> interfaces, for example - DateTimeInterface exists specifically to have
> mutable and immutable implementations, and a return type of $this would
> explicitly prevent that.
> 
> If we add ": $this" alongside ": void", I wonder where that takes us next -
> what other constraints on a function can be expressed using that notation
> which aren't contracts on the value seen by the caller? If we don't want to
> explore that question, should we avoid adding ": $this"?
> 
> Regards,
> -- 
> Rowan Tommins
> [IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Static return type

[Dik Takken]

On 09-01-2020 17:52, Andreas Hennings wrote:
> On Thu, 9 Jan 2020 at 16:31, Nikita Popov  wrote:
> 
>> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins 
>> wrote:
>>
>> An argument could be made that $this does also specify a certain contract
>> to the caller: That the API may be used fluently or not without change in
>> functionality. That is
>>
>> $foo->setBar();
>> $foo->setBaz();
>>
>> must be strictly equivalent to
>>
>> $foo
>>->setBar()
>>->setBaz()
>> ;
>>
>> The same is not the case for a plain "static" type. In fact, I think that
>> for all other uses of "static" outside of fluent interfaces, not using the
>> return value would be a programming error.
>>
>> But still, this kind of contract is not a type-system contract, and I'm not
>> sure it's a good idea to mix other types of API contracts into the type
>> system in this fashion.
>>
> 
> We currently don't have another "system" where this kind of info could be
> specified.

How about:

  public fluent function doWhatever(): static

Perhaps this could be introduced at some point in the future to enforce
returning $this.

> And in this case, $this also implies static, so if we would use whichever
> other system to specify $this, the type hint "static" would become
> redundant.
> 
> "@return $this" is common in phpdoc (*) since a while, and so far I have
> not seen any problems with it.
> 
> If we ask "where does this lead?", one natural next step might be to
> specifically say that the return type is the same type, but NOT $this.
> So, a promise that we really get a new object which we can modify without
> changing the original object.
> 
> I don't know how we would express this. Perhaps ": clone", but this would
> be too specific imo, because whether it is a clone is an implementation
> detail.

Maybe ": new" ?

Regards,
Dik Takken

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Static return type

[Andreas Hennings]

On Thu, 9 Jan 2020 at 16:31, Nikita Popov  wrote:

> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins 
> wrote:
>
> > On Thu, 9 Jan 2020 at 14:23, Andreas Hennings 
> wrote:
> >
> > > > However, $this is not a real type, and it is unclear what the
> advantage
> > > of specifying $this rather than static would be from a type system
> level
> > > perspective.
> > >
> > > Perhaps not from a "type system level", but from a more broad "enforced
> > > contract" level.
> > > E.g. IDEs or code inspection tools can warn if a method will not return
> > > $this.
> > > This also means recursive calls also need to return $this instead of
> > > static.
> > >
> > > class C {
> > >   function foo(): static {
> > > return clone $this;
> > >   }
> > >   function bar(): $this {
> > > return $this->foo();  // IDE can complain.
> > >   }
> > > }
> > >
> >
> >
> > I think there are two different purposes for annotating return types:
> >
> > 1) Contracts that tell the caller what values they should expect when
> > calling the function.
> > 2) Constraints on the implementation which don't affect the caller, but
> > allow the author to catch certain bugs.
> >
> > The primary purpose, in my mind, is (1), with (2) generally coming as a
> > side-effect: if your contract is to return an int, then tools can warn
> you
> > when you don't.
> >
> > All concrete types can be seen this way: scalars, classes, and
> pseudo-types
> > like "iterable" are all contracts that calling code can rely on. "self",
> > "parent", and "static" fit into that list fine, because they're
> ultimately
> > specifying a class name.
> >
> > The special "void" keyword doesn't actually make sense as a contract
> given
> > PHP's calling convention - as far as the calling code's concerned, it's
> > equivalent to "null". So it exists only for purpose (2), constraining the
> > implementation for the benefit of the function's author.
> >
> > $this would fit into the same category - as far as calling code is
> > concerned it is equivalent to "static", unless they're doing something
> very
> > specific with object identity. This makes it an odd constraint on
> > interfaces, for example - DateTimeInterface exists specifically to have
> > mutable and immutable implementations, and a return type of $this would
> > explicitly prevent that.
> >
> > If we add ": $this" alongside ": void", I wonder where that takes us
> next -
> > what other constraints on a function can be expressed using that notation
> > which aren't contracts on the value seen by the caller? If we don't want
> to
> > explore that question, should we avoid adding ": $this"?
> >
>
> An argument could be made that $this does also specify a certain contract
> to the caller: That the API may be used fluently or not without change in
> functionality. That is
>
> $foo->setBar();
> $foo->setBaz();
>
> must be strictly equivalent to
>
> $foo
>->setBar()
>->setBaz()
> ;
>
> The same is not the case for a plain "static" type. In fact, I think that
> for all other uses of "static" outside of fluent interfaces, not using the
> return value would be a programming error.
>
> But still, this kind of contract is not a type-system contract, and I'm not
> sure it's a good idea to mix other types of API contracts into the type
> system in this fashion.
>

We currently don't have another "system" where this kind of info could be
specified.
And in this case, $this also implies static, so if we would use whichever
other system to specify $this, the type hint "static" would become
redundant.

"@return $this" is common in phpdoc (*) since a while, and so far I have
not seen any problems with it.

If we ask "where does this lead?", one natural next step might be to
specifically say that the return type is the same type, but NOT $this.
So, a promise that we really get a new object which we can modify without
changing the original object.

I don't know how we would express this. Perhaps ": clone", but this would
be too specific imo, because whether it is a clone is an implementation
detail.

In phpdoc (*) there is no common syntax for "static, but not $this", so
perhaps it was not needed yet.

And in fact, an immutable wither can safely return the original object if
no changes are needed, if other methods are also immutable.

(*) When I say "phpdoc", I really mean the kinds of docs that people
commonly use in the wild, and that are understood by IDEs.
Which of that is documented and supported by the phpdoc library is a
different question.



>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Static return type

[Nikita Popov]

On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins 
wrote:

> On Thu, 9 Jan 2020 at 14:23, Andreas Hennings  wrote:
>
> > > However, $this is not a real type, and it is unclear what the advantage
> > of specifying $this rather than static would be from a type system level
> > perspective.
> >
> > Perhaps not from a "type system level", but from a more broad "enforced
> > contract" level.
> > E.g. IDEs or code inspection tools can warn if a method will not return
> > $this.
> > This also means recursive calls also need to return $this instead of
> > static.
> >
> > class C {
> >   function foo(): static {
> > return clone $this;
> >   }
> >   function bar(): $this {
> > return $this->foo();  // IDE can complain.
> >   }
> > }
> >
>
>
> I think there are two different purposes for annotating return types:
>
> 1) Contracts that tell the caller what values they should expect when
> calling the function.
> 2) Constraints on the implementation which don't affect the caller, but
> allow the author to catch certain bugs.
>
> The primary purpose, in my mind, is (1), with (2) generally coming as a
> side-effect: if your contract is to return an int, then tools can warn you
> when you don't.
>
> All concrete types can be seen this way: scalars, classes, and pseudo-types
> like "iterable" are all contracts that calling code can rely on. "self",
> "parent", and "static" fit into that list fine, because they're ultimately
> specifying a class name.
>
> The special "void" keyword doesn't actually make sense as a contract given
> PHP's calling convention - as far as the calling code's concerned, it's
> equivalent to "null". So it exists only for purpose (2), constraining the
> implementation for the benefit of the function's author.
>
> $this would fit into the same category - as far as calling code is
> concerned it is equivalent to "static", unless they're doing something very
> specific with object identity. This makes it an odd constraint on
> interfaces, for example - DateTimeInterface exists specifically to have
> mutable and immutable implementations, and a return type of $this would
> explicitly prevent that.
>
> If we add ": $this" alongside ": void", I wonder where that takes us next -
> what other constraints on a function can be expressed using that notation
> which aren't contracts on the value seen by the caller? If we don't want to
> explore that question, should we avoid adding ": $this"?
>

An argument could be made that $this does also specify a certain contract
to the caller: That the API may be used fluently or not without change in
functionality. That is

$foo->setBar();
$foo->setBaz();

must be strictly equivalent to

$foo
   ->setBar()
   ->setBaz()
;

The same is not the case for a plain "static" type. In fact, I think that
for all other uses of "static" outside of fluent interfaces, not using the
return value would be a programming error.

But still, this kind of contract is not a type-system contract, and I'm not
sure it's a good idea to mix other types of API contracts into the type
system in this fashion.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Static return type

[Rowan Tommins]

On Thu, 9 Jan 2020 at 14:23, Andreas Hennings  wrote:

> > However, $this is not a real type, and it is unclear what the advantage
> of specifying $this rather than static would be from a type system level
> perspective.
>
> Perhaps not from a "type system level", but from a more broad "enforced
> contract" level.
> E.g. IDEs or code inspection tools can warn if a method will not return
> $this.
> This also means recursive calls also need to return $this instead of
> static.
>
> class C {
>   function foo(): static {
> return clone $this;
>   }
>   function bar(): $this {
> return $this->foo();  // IDE can complain.
>   }
> }
>


I think there are two different purposes for annotating return types:

1) Contracts that tell the caller what values they should expect when
calling the function.
2) Constraints on the implementation which don't affect the caller, but
allow the author to catch certain bugs.

The primary purpose, in my mind, is (1), with (2) generally coming as a
side-effect: if your contract is to return an int, then tools can warn you
when you don't.

All concrete types can be seen this way: scalars, classes, and pseudo-types
like "iterable" are all contracts that calling code can rely on. "self",
"parent", and "static" fit into that list fine, because they're ultimately
specifying a class name.

The special "void" keyword doesn't actually make sense as a contract given
PHP's calling convention - as far as the calling code's concerned, it's
equivalent to "null". So it exists only for purpose (2), constraining the
implementation for the benefit of the function's author.

$this would fit into the same category - as far as calling code is
concerned it is equivalent to "static", unless they're doing something very
specific with object identity. This makes it an odd constraint on
interfaces, for example - DateTimeInterface exists specifically to have
mutable and immutable implementations, and a return type of $this would
explicitly prevent that.

If we add ": $this" alongside ": void", I wonder where that takes us next -
what other constraints on a function can be expressed using that notation
which aren't contracts on the value seen by the caller? If we don't want to
explore that question, should we avoid adding ": $this"?

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Static return type

[Nicolas Grekas]

> Of course this ": $this" could be added later in the future.
> But this would have the risk that people start adding ": static" on methods
> that really return $this.
>

I second $this. I also would like to be able to declare `function foo():
$this` at the same time as `function foo(): static` so that we can use the
most accurate description right away.

Although I'm not into the C part of the proposal, if I may have a
suggestion here, it would be to implement the check *at compile time*. Like
nullable return types check at compile time that `return null;` is used
instead of just `return;`, I think a `$this` return type could and should
enforce `return $this;` on all return point of such methods. That would
also make the check free at runtime.

Cheers,
Nicolas

Re: [PHP-DEV] [RFC] Static return type

[Andreas Hennings]

On Thu, 9 Jan 2020 at 15:22, Andreas Hennings  wrote:

> > However, $this is not a real type, and it is unclear what the advantage
> of specifying $this rather than static would be from a type system level
> perspective.
>
> Perhaps not from a "type system level", but from a more broad "enforced
> contract" level.
> E.g. IDEs or code inspection tools can warn if a method will not return
> $this.
> This also means recursive calls also need to return $this instead of
> static.
>

> class C {
>   function foo(): static {
> return clone $this;
>   }
>   function bar(): $this {
> return $this->foo();  // IDE can complain.
>   }
> }
>


Of course this ": $this" could be added later in the future.
But this would have the risk that people start adding ": static" on methods
that really return $this.
This would cause confusion if later some packages introduce ": $this", but
others are still behind.

namespace oldpackage;
class B {
  function foo(): static { // Actually returns $this, not just static.
return $this;
  }
}

namespace newpackage;
class C extends B {
  function foo(): $this {
return parent::foo();  // Should the IDE complain?
  }
}


>
>
> On Thu, 9 Jan 2020 at 15:07, Larry Garfield 
> wrote:
>
>> On Wed, Jan 8, 2020, at 5:42 AM, Nikita Popov wrote:
>> > Hi internals,
>> >
>> > I would like to propose the following RFC, which allows using "static"
>> as a
>> > return type:
>> >
>> > https://wiki.php.net/rfc/static_return_type
>> >
>> > While I'm personally not a fan of late static binding, we do support it
>> and
>> > people do use it quite heavily, so I think we should also support it in
>> > return types.
>> >
>> > Regards,
>> > Nikita
>>
>>
>> Is "squee!" an appropriate response on the list?  For interface authors
>> this is a huge deal.
>>
>> --Larry Garfield
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] [RFC] Static return type

[Andreas Hennings]

> However, $this is not a real type, and it is unclear what the advantage
of specifying $this rather than static would be from a type system level
perspective.

Perhaps not from a "type system level", but from a more broad "enforced
contract" level.
E.g. IDEs or code inspection tools can warn if a method will not return
$this.
This also means recursive calls also need to return $this instead of static.

class C {
  function foo(): static {
return clone $this;
  }
  function bar(): $this {
return $this->foo();  // IDE can complain.
  }
}


On Thu, 9 Jan 2020 at 15:07, Larry Garfield  wrote:

> On Wed, Jan 8, 2020, at 5:42 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > I would like to propose the following RFC, which allows using "static"
> as a
> > return type:
> >
> > https://wiki.php.net/rfc/static_return_type
> >
> > While I'm personally not a fan of late static binding, we do support it
> and
> > people do use it quite heavily, so I think we should also support it in
> > return types.
> >
> > Regards,
> > Nikita
>
>
> Is "squee!" an appropriate response on the list?  For interface authors
> this is a huge deal.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Static return type

[Larry Garfield]

On Wed, Jan 8, 2020, at 5:42 AM, Nikita Popov wrote:
> Hi internals,
> 
> I would like to propose the following RFC, which allows using "static" as a
> return type:
> 
> https://wiki.php.net/rfc/static_return_type
> 
> While I'm personally not a fan of late static binding, we do support it and
> people do use it quite heavily, so I think we should also support it in
> return types.
> 
> Regards,
> Nikita


Is "squee!" an appropriate response on the list?  For interface authors this is 
a huge deal.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Static return type

[Ben Ramsey]

> On Jan 8, 2020, at 05:42, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I would like to propose the following RFC, which allows using "static" as a
> return type:
> 
> https://wiki.php.net/rfc/static_return_type
> 
> While I'm personally not a fan of late static binding, we do support it and
> people do use it quite heavily, so I think we should also support it in
> return types.
> 
> Regards,
> Nikita


Yes, please!

> For the fluent method example above, many projects will use a @return $this
> annotation, rather than @return static.

In my own code, I usually use `self` to mean “return the same instance.” While 
I know that, in practice, the use of `self` is identical to using the class 
name as the return type, it seems natural to designate as practice (among my 
team) that `self` always means itself and should never refer to an instance 
with different identity.

-Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] Static return type

[Benjamin Morel]

>
> I would like to propose the following RFC, which allows using "static" as a
> return type:
> https://wiki.php.net/rfc/static_return_type



Big +1 from me as well. I actually asked why this wasn't supported back in
2015:

static return type in PHP 7 interfaces


— Benjamin

Re: [PHP-DEV] [RFC] Static return type

[Paul M. Jones]

> On Jan 8, 2020, at 05:42, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I would like to propose the following RFC, which allows using "static" as a
> return type:
> 
> https://wiki.php.net/rfc/static_return_type

Very happy to see this.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Static return type

[Rowan Tommins]

On Wed, 8 Jan 2020 at 11:42, Nikita Popov  wrote:

> I would like to propose the following RFC, which allows using "static" as a
> return type:
>
> https://wiki.php.net/rfc/static_return_type
>
> While I'm personally not a fan of late static binding, we do support it and
> people do use it quite heavily, so I think we should also support it in
> return types.
>


A big +1 from me; I'd probably have assumed it would work and be
disappointed when it didn't.

I can see why late static binding isn't to everyone's taste as a concept,
but it is very useful to emulate other features like named constructors, as
you show in the RFC.

The fluent interface example is interesting, because it doesn't actually
involve late static binding at all, we just need some way to say "what
comes out is the same type as what goes in".

Regards,
-- 
Rowan Tommins
[IMSoP]

[PHP-DEV] [RFC] Static return type

[Nikita Popov]

Hi internals,

I would like to propose the following RFC, which allows using "static" as a
return type:

https://wiki.php.net/rfc/static_return_type

While I'm personally not a fan of late static binding, we do support it and
people do use it quite heavily, so I think we should also support it in
return types.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Fleshgrinder]

On 4/19/2016 12:02 AM, Lester Caine wrote:
> On 18/04/16 20:08, Fleshgrinder wrote:
>> This is however a useful shortcut and shortcuts are good things in
>> terms of usability if done write. Think of  +  vs. right click
 copy (or any other example of useful keyboard shortcuts).
> 
> Except when some sod adds a  or decides left click is quicker ...
> all of which are in use on one or other Linux desktop tool :(
> 
> A CONSISTENT way of doing things would save a lot of time, so adding
> even deeper levels of functionality is just overkill ...
> 

Everything that is good can backfire if overused. We need to ensure that
we do not do that and the fact that we are discussing it right here
shows that we are not taking the decision lightly. :)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

On 4/18/16 2:24 PM, Stanislav Malyshev wrote:


I would like to note in general that following the latest fashion in
academic development is not always a good idea for PHP. It's fine when
you experiment with academic languages, but when you have language that
a) focused on simplicity and low entrance barrier and b) is in
production use by millions and has 20 years of existing practices,
libraries and habits, we have to be a bit more wary, I think. I am *not*
saying we should not improve, or ignore academic developments, I am
saying that we should be careful with not jumping to the idea-of-the-day
bandwagon too fast, before it is clear it is good and necessary for PHP.


...

I agree with Stas, not just this paragraph but pretty all of the email.

Within the context of today's PHP language, practices, and the tried and 
true libraries and frameworks we rely on, I don't know how, for certain 
necessary semantics, to improve on Something or null return contracts.


I all honesty, I've looked for alternatives that satisfy a specific type 
but I can't find anything better.


For example, I use the active record ORM from the Yii 2 framework. My 
User model class therefore extends ActiveRecord. If I search for a User 
record matching given criteria (e.g. an email address) the parent class 
needs a generic way represent that no matching record exists and that 
this is not an exception.


The convention in PHP is to return null in this situation. I have tried 
to imagine how the search method might return an instance of the User 
model class that represents "not a user record", i.e. the absence of any 
user matching the search criteria. PHP's version of OOP seems not to 
have a intrinsic feature for a function to return an object with type 
Something but void of any Something object instance.


If PHP has nothing to model this, what convention can we invent as a 
workaround to *encode* "empty" in an actual instance of ActiveRecord or 
any subtype? A magic property can conflict with the app's model 
attributes. But an ActiveRecord::isEmpty() method could work. This 
satisfies the desire to return a specific subtype of ActiveRecord (e.g. 
User) but it also introduces hazardous complexity: what do you do with 
an instance in which the model's attributes, including primary key,  are 
valid but isEmpty() returns true, or vise versa.


Moreover, in what way is this better than returning PHP null? What have 
we gained with this isEmpty() conventions?


Tom




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Lester Caine]

On 18/04/16 20:08, Fleshgrinder wrote:
> This is however a useful shortcut and shortcuts are good things in
> terms of usability if done write. Think of  +  vs. right click
>> > copy (or any other example of useful keyboard shortcuts).

Except when some sod adds a  or decides left click is quicker ...
all of which are in use on one or other Linux desktop tool :(

A CONSISTENT way of doing things would save a lot of time, so adding
even deeper levels of functionality is just overkill ...

-- 
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 Return Type Declaration

[Fleshgrinder]

On 4/18/2016 7:22 AM, Marcio Almada wrote:
> 2016-04-17 23:56 GMT-04:00 Larry Garfield :
>> Rather than debate the relative merits of Null as a concept, since I think
>> all agree removing Null from the language is not even a thing, what do you
>> think of my recommendation to NOT have the ? shorthand for "or null" on
>> types, but keep the |null for union types?  That is, if you want to return
>> Foo or null, you have to use the long-hand version:
>>
>> function foo($a) : Foo|null
>>
>> That
>>
>> 1) Allows for explicit or-null behavior.
>> 2) Doesn't make it quite so easy, which hopefully discourages (but does
>> not prohibit) its usage.
>> 3) Neatly avoids the ?Foo / Foo? question entirely.
>>
>> I think that's a win-win arrangement.
>>
> I can agree with that.
> 
> Language design wise, if you have no way to forecast how language features
> independently proposed are going to interact then it's a good idea to have
> a converging strategy. Fortunately, this seems to be happening almost
> spontaneously towards union types representation, as in the "multiple
> catch" RFC (https://wiki.php.net/rfc/multiple-catch) now in voting phase.
> 
> Even if we decide not to commit to a full union types implementation now,
> the design process will be much easier in the future if we decide to use
> Foo|null instead of Foo? or ?Foo and we will not end up with 2 or 3 ways
> alternative to declare the same thing.
> 

I actually do not see a problem with the shorthand notation. I am
usually an extreme opponent of duplicated or aliased functionality
because it increases the cognitive load to keep all this crap in your
mind. This is however a useful shortcut and shortcuts are good things in
terms of usability if done write. Think of  +  vs. right click
> copy (or any other example of useful keyboard shortcuts). The usage of
*null* as an union type is the most common case compared to all the
others that are truly rare in comparison.

There are other shortcuts in PHP that are perfect:

- Iterator vs. Generator: they can achieve the exact same thing but
  slightly different and a generator can almost always be used to
  replace an iterator with less code, even if the special effects of
  it are irrelevant.
- `$x = $x + $y` vs. `$x += $y`: we have many of those and that is just
  fine as it is.
- `$x = $x + 1` vs. `++$x` vs. `$x++`: ditto
- `

signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Lester Caine]

On 18/04/16 19:24, Stanislav Malyshev wrote:
> If your database died, your DB-bound code is not going
> to fix it. With or without nulls - it has to just fail and wait for
> somebody to fix it. There's no need to overcomplicate that.

If the DB read failed due to the connection being lost, then that is a
case for an exception and out of flow events? The 'null' would be
returned when an active connection has no data to return because a
search or query has produced none. Larry would probably be looking to
check the 'no_of_recs' to see if there were any results but then you
still have to read the result if there is one ... overcomplicating the
simple solution?

( ADOdb check the connection is still valid as part of the query prep
and run and changes the work flow if required )

-- 
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 Return Type Declaration

[Fleshgrinder]

On 4/18/2016 8:24 PM, Stanislav Malyshev wrote:
>> to have them calls them a "billion dollar mistake", many languages
>> actively avoid having NULL in favor of something deliberately more
>> structured.  NULLs are a very common cause of avoidable fatal errors in
>> many languages (including PHP). NULLs are rude to users of your API, as
>> it balloons the error handling code they need to deal with.
> 
> I think this description is misleading in a way. Nulls are immediate
> causes of many errors, technically, in a meaning that "if I find null
> where I expected to have DB connection, I get an error" - but this is
> only a technical cause. The *real* cause is the failure to check whether
> your attempt to connect to the database succeeded, or that you have
> proper DB configuration, or such, and null is just a symptom of that
> error - and that error is not automagically fixed by having some other
> object instead of null. You have to actually design and write code for
> it, there's no replacement for it.
> 
> So declaring null "cause of all evils" is ignoring the real causes and
> blaming immediate technical cause instead, and it would not be helpful.
> It is true that for some languages with more complex type systems it is
> possible to largely get rid of nulls by using those complex types and
> ensure type system controls for all checks at least to be present (note
> that doesn't guarantee proper function either, since no type system can
> ensure you handle the case of missing DB connection properly, it just
> can ensure you have a branch for it). But that requires much more
> complex and involved type system that PHP has - or, in my opinion,
> should have.
> 

I agree with Stanislav here. *NULL* is not evil per se and just because
some functional languages get some attention right now does not mean
that they solved the biggest mistake in CS history. On the contrary,
they just invented another way of handling it by introducing new types
that require more book keeping and by refusing to compile if they
encounter a place where proper handling is missing.

As I wrote earlier, we could introduce such a feature into the language.
However, static code analyzers can already provide this functionality.
People just need to use them.

TL;DR *NULL* is just fine if used correctly and we cannot make sure that
people use it correctly.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Stanislav Malyshev]

Hi!

> I am not sure what you're implying by "some people have no appreciation
> of the usefulness of"... I am well aware of NULL's use cases.  I am also
> well aware that the general zeitgeist in the language development
> community is that they're dangerous; the designer of the first language

I would like to note in general that following the latest fashion in
academic development is not always a good idea for PHP. It's fine when
you experiment with academic languages, but when you have language that
a) focused on simplicity and low entrance barrier and b) is in
production use by millions and has 20 years of existing practices,
libraries and habits, we have to be a bit more wary, I think. I am *not*
saying we should not improve, or ignore academic developments, I am
saying that we should be careful with not jumping to the idea-of-the-day
bandwagon too fast, before it is clear it is good and necessary for PHP.

As an example, I don't see how exactly eliminating null would be good
for PHP, or doing *anything* with null for that matter.

> to have them calls them a "billion dollar mistake", many languages
> actively avoid having NULL in favor of something deliberately more
> structured.  NULLs are a very common cause of avoidable fatal errors in
> many languages (including PHP). NULLs are rude to users of your API, as
> it balloons the error handling code they need to deal with.

I think this description is misleading in a way. Nulls are immediate
causes of many errors, technically, in a meaning that "if I find null
where I expected to have DB connection, I get an error" - but this is
only a technical cause. The *real* cause is the failure to check whether
your attempt to connect to the database succeeded, or that you have
proper DB configuration, or such, and null is just a symptom of that
error - and that error is not automagically fixed by having some other
object instead of null. You have to actually design and write code for
it, there's no replacement for it.

So declaring null "cause of all evils" is ignoring the real causes and
blaming immediate technical cause instead, and it would not be helpful.
It is true that for some languages with more complex type systems it is
possible to largely get rid of nulls by using those complex types and
ensure type system controls for all checks at least to be present (note
that doesn't guarantee proper function either, since no type system can
ensure you handle the case of missing DB connection properly, it just
can ensure you have a branch for it). But that requires much more
complex and involved type system that PHP has - or, in my opinion,
should have.

> I am on record and will continue to be on record that null is *usually*
> wrong.  I consider that position entirely justified, as does the
> academic CS community.  I am also now on record suggesting that we use
> union types to allow type-or-null returns/parameters, which you're
> welcome to quote me on. :-)

I think this position is way too narrow, simplistic and detached from
real language use towards abstract academic purity. There are tons of
causes where using null is completely fine and exactly what is needed. I
also think union types is a great and unnecessary complication of the
language and in order to do them properly we'd need lots of facilities
PHP does not have (like type pattern matching and static compilation)
and I am not sure it should have - ones looking for Haskell know where
to find it.
And there are a lot of cases where failing on null is exactly what one
needs - if it doesn't work, just fail and let somebody come and check
what is going on. If your database died, your DB-bound code is not going
to fix it. With or without nulls - it has to just fail and wait for
somebody to fix it. There's no need to overcomplicate that.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Lester Caine]

On 18/04/16 17:57, Larry Garfield wrote:
> On 4/18/16 3:00 AM, Lester Caine wrote:
>> On 18/04/16 04:56, Larry Garfield wrote:
>>> 2) Doesn't make it quite so easy, which hopefully discourages (but does
>>> not prohibit) its usage.
>> This implies that using 'null' is wrong ... and is a slippery slope to
>> then 'disabling' null where some people think it should be removed. If
>> PHP development is making these sort of decisions it should be clear
>> that is the intention, not just 'hopefully discourages' things that some
>> people have no appreciation of the usefulness of!
> 
> I am not sure what you're implying by "some people have no appreciation
> of the usefulness of"... I am well aware of NULL's use cases.  I am also
> well aware that the general zeitgeist in the language development
> community is that they're dangerous; the designer of the first language
> to have them calls them a "billion dollar mistake", many languages
> actively avoid having NULL in favor of something deliberately more
> structured.  NULLs are a very common cause of avoidable fatal errors in
> many languages (including PHP). NULLs are rude to users of your API, as
> it balloons the error handling code they need to deal with.

With a properly structured code flow, NULL is the ONLY logical solution
to elements of the data that do not physically exist. And in my book
that includes where we run out of whole records when running that work
flow. PHP is a scripting language that works well with these flows of
data, and NULL is certainly NOT a mistake IN that workflow. So in order
to remove NULL you need to come up with a reason why the SQL standard is
wrong and produce a new specification that can replace it ... and
'exception' is just another mistake that needs eliminating where that is
not appropriate when a simple NULL currently does the job more than
adequately.

> I am on record and will continue to be on record that null is *usually*
> wrong.  I consider that position entirely justified, as does the
> academic CS community.  I am also now on record suggesting that we use
> union types to allow type-or-null returns/parameters, which you're
> welcome to quote me on. :-)
> 
> Are you comfortable with the compromise position I've proposed?

As long as I can simply wipe any use of ANY of this type code overload
from my libraries and keep it out of ANY of the code PHP functionality
it so that the database extensions still handle 'null' exactly as it is
designed to work then that is all I need. I don't see ANY need to add
internally the very code you are complaining we need to add externally
removing the simple flexibility that provides. So I don't see the need
for any compromise ... just scrap the whole waste of time adding
unnecessary code and documenting why you think PHP is currently so
broken ...

-- 
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 Return Type Declaration

[Larry Garfield]

On 4/18/16 3:00 AM, Lester Caine wrote:

On 18/04/16 04:56, Larry Garfield wrote:

2) Doesn't make it quite so easy, which hopefully discourages (but does
not prohibit) its usage.

This implies that using 'null' is wrong ... and is a slippery slope to
then 'disabling' null where some people think it should be removed. If
PHP development is making these sort of decisions it should be clear
that is the intention, not just 'hopefully discourages' things that some
people have no appreciation of the usefulness of!


I am not sure what you're implying by "some people have no appreciation 
of the usefulness of"... I am well aware of NULL's use cases.  I am also 
well aware that the general zeitgeist in the language development 
community is that they're dangerous; the designer of the first language 
to have them calls them a "billion dollar mistake", many languages 
actively avoid having NULL in favor of something deliberately more 
structured.  NULLs are a very common cause of avoidable fatal errors in 
many languages (including PHP). NULLs are rude to users of your API, as 
it balloons the error handling code they need to deal with.


I am on record and will continue to be on record that null is *usually* 
wrong.  I consider that position entirely justified, as does the 
academic CS community.  I am also now on record suggesting that we use 
union types to allow type-or-null returns/parameters, which you're 
welcome to quote me on. :-)


Are you comfortable with the compromise position I've proposed?

--
--Larry Garfield


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Lester Caine]

On 18/04/16 04:56, Larry Garfield wrote:
> 2) Doesn't make it quite so easy, which hopefully discourages (but does
> not prohibit) its usage.

This implies that using 'null' is wrong ... and is a slippery slope to
then 'disabling' null where some people think it should be removed. If
PHP development is making these sort of decisions it should be clear
that is the intention, not just 'hopefully discourages' things that some
people have no appreciation of the usefulness of!

-- 
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 Return Type Declaration

[Marcio Almada]

Hi!

2016-04-17 23:56 GMT-04:00 Larry Garfield :

> On 04/17/2016 02:19 AM, Fleshgrinder wrote:
>
>> Everything always has pros and cons and I do not think that there is one
>> answer to all of these questions. Different languages handle this
>> problem differently. PHP has `NULL` and we should keep it this way. To
>> minimize bugs resulting from unchecked `NULL` usage a compiler feature
>> could be implemented that warns a developer in such cases. We already
>> have it for uncatched exceptions (although IDEs are currently not
>> telling one about that; Eclipse does in Java though).
>>
>
> Rather than debate the relative merits of Null as a concept, since I think
> all agree removing Null from the language is not even a thing, what do you
> think of my recommendation to NOT have the ? shorthand for "or null" on
> types, but keep the |null for union types?  That is, if you want to return
> Foo or null, you have to use the long-hand version:
>
> function foo($a) : Foo|null
>
> That
>
> 1) Allows for explicit or-null behavior.
> 2) Doesn't make it quite so easy, which hopefully discourages (but does
> not prohibit) its usage.
> 3) Neatly avoids the ?Foo / Foo? question entirely.
>
> I think that's a win-win arrangement.
>
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I can agree with that.

Language design wise, if you have no way to forecast how language features
independently proposed are going to interact then it's a good idea to have
a converging strategy. Fortunately, this seems to be happening almost
spontaneously towards union types representation, as in the "multiple
catch" RFC (https://wiki.php.net/rfc/multiple-catch) now in voting phase.

Even if we decide not to commit to a full union types implementation now,
the design process will be much easier in the future if we decide to use
Foo|null instead of Foo? or ?Foo and we will not end up with 2 or 3 ways
alternative to declare the same thing.

Cheers,
Márcio

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Larry Garfield]

On 04/17/2016 02:19 AM, Fleshgrinder wrote:

Everything always has pros and cons and I do not think that there is one
answer to all of these questions. Different languages handle this
problem differently. PHP has `NULL` and we should keep it this way. To
minimize bugs resulting from unchecked `NULL` usage a compiler feature
could be implemented that warns a developer in such cases. We already
have it for uncatched exceptions (although IDEs are currently not
telling one about that; Eclipse does in Java though).


Rather than debate the relative merits of Null as a concept, since I 
think all agree removing Null from the language is not even a thing, 
what do you think of my recommendation to NOT have the ? shorthand for 
"or null" on types, but keep the |null for union types?  That is, if you 
want to return Foo or null, you have to use the long-hand version:


function foo($a) : Foo|null

That

1) Allows for explicit or-null behavior.
2) Doesn't make it quite so easy, which hopefully discourages (but does 
not prohibit) its usage.

3) Neatly avoids the ?Foo / Foo? question entirely.

I think that's a win-win arrangement.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Fleshgrinder]

On 4/15/2016 5:50 PM, Larry Garfield wrote:
> That there are a few small cases where PHP's current design makes NULL a
> reasonable sentinel value (custom iterators, fread() as you mention,
> etc.) does not mean that in most cases, returning ValueObject|Null is
> rude and abusive to users of your API.  Yes, end-of-file is not an
> exceptional case so should not throw an exception.  I completely agree
> there.  But "user not found" I'd argue is.  (Or rather, if it's not an
> exceptional case your data model is kinda broken to begin with, because
> why are you asking for a missing user?)  Or you're better off having an
> "empty" value instead, such as an anonymous user object.  That's still
> type safe.
> 

I disagree here. Your user example with the anonymous user object works
if I am asking for e.g. the creation of a session but it is a very
different situation if I would be asking for a user profile. The fact
that a user might have deleted her account is not an exceptional case,
is is to be expected and should be handled accordingly. How is up to the
caller. Otherwise any `array_key_exists($k, $a)` should result in an
exception or some default value according to your logic here.

I completely agree that `NULL` is not the best type and others languages
have other means to solve the issue but absolutely every language has
some way to indicate the absence of a meaningful value. PHP has `NULL`
like many others and that is fine. The problem is not that we have
`NULL` the problem is that it is just too often not checked if it can be
`NULL`.

Rust and many functional language solve this with an Option or Maybe
that requires creation, allocation, and userland checks for every return
and the compilers fail if you do not unpack it.

Ceylon solves this with union types as we are discussing it right now,
however, the difference to other languages is that the compiler will
fail if you are not checking the return value and bugs are avoided in
this way. This is something that we could adopt.

http://ceylon-lang.org/documentation/faq/language-design/#optional_types

The absence of something must be modellable.

class ConstraintViolation {

private ?Throwable $cause;

private string $message;

public function __construct(
string $message,
?Throwable $cause = null
) {
$this->message = $message;
$this->cause = $cause;
}

public function getCause(): ?Throwable {
return $this->cause;
}

public function hasCause(): bool {
return isset($this->cause);
}

// ...

}

An example of a class I was just working on. How could, would, or should
one model this without `NULL`? Throwing an exception? It is not
exceptional for such an object and expected that there is no cause
available. It is up to the caller how she wants to take care of this.

/** @var ConstraintViolation $violation */
if ($violation->hasCause()) {
// Handle cause ...
}

$cause = $violation->getCause();
if (isset($cause)) {
// Handle cause ...
}

// Or maybe we just want it stringified?
// Works nicely with `NULL`. :)
echo $violation->getCause();

Throwing exceptions everywhere for non exceptional cases is a code smell
too and I see that ever to often in current open source code. Especially
throwing extremely low-level exception everywhere for real errors from
which one should not recover (e.g. `InvalidArgumentException`) because
they indicate developer mistakes and only add a lot of checks in
production for no reason. That being said, the above could be rewritten to.

class ConstraintViolation {

public function getCause(): Throwable {}

public function hasCause(): bool {}

}

This would mean that PHP emits an Error if someone calls `getCause` and
there is no cause and there would be only one way to check: `hasCause`.
This is a valid design decision since it minimizes the amount of
possibilities to work with the class and avoids `NULL` altogether.
However, the caller code did not really become less verbose; as was
already illustrated in the above examples. Plus, the ability to directly
use the `__toString`ability paired with `NULL` in a string is gone.

Everything always has pros and cons and I do not think that there is one
answer to all of these questions. Different languages handle this
problem differently. PHP has `NULL` and we should keep it this way. To
minimize bugs resulting from unchecked `NULL` usage a compiler feature
could be implemented that warns a developer in such cases. We already
have it for uncatched exceptions (although IDEs are currently not
telling one about that; Eclipse does in Java though).

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

On 4/15/16 12:22 AM, Levi Morrison wrote:


My point is that `foo(bar(), $val)` won't die because bar may return
null. Bar is expected to return null sometimes.

For example, let's consider an administrator page where they look up
user information based on an identifier. The routine we'll use will
have this signature:

 function get_user(string $id): User | Null;

It is possible for an identifier to not exist and this is not an error
(database successfully returned no results). If there is no User data
to display then it makes sense for the UI to present that differently.
Thus it makes sense to pass that User | Null onto the code that will
present it:

 $user_data = get_user($id);
 // ...
 $user_html = render_user_data($user_data);

In fact this is a common operation that is encountered in many code
bases (I think every single one I've ever looked at).


This is a good example.

My opinion is that *because* get_user() can return null (a red flag) I 
prefer to see explicit handing of the null case before doing anything else.


If I would end up with `render_user_data(get_user($id))` I would 
consider it fair to not hint the param because I didn't earn it. I 
invented the faux docblock tag @sorry for this kind of thing.


Tom


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

On 4/14/16 8:48 PM, Larry Garfield wrote:


I am highly, highly sceptical about nullable parameters or returns, and
frankly would rather they were not included in the language.  By nature
they undermine type safety.  At best, they indicate to all callers
"*every* time you call this function, you MUST put is_null() around it
or your program may fail randomly."


Yes.



While that's better to know
explicitly than not (which is the case for any untyped return, aka any
PHP code pre-7.0), it would be better still to, well, not have to worry
about that billion dollar mistake[1] cropping up in my code.


I agree.

To be clear, I do not intend the RFC to encourage nullable return or 
suggest that it's a fine thing to use. But given where we are, it's hard 
to imagine how to extirpate it.


When we started using PHP 7.0 type, initially when authoring new models 
(and using Yii2), it immediately became clear that we lacked two things: 
this and void returns. We're getting the latter in 7.1. It would be very 
nice if we could have both.


I'm a practical PHP user, with a generally conservative attitude to the 
language, often unmoved by proposals add a feature because some other 
more fashionable language has it (I call it language envy, to borrow 
from Freud). And while PHP 7.0 is good, I'd rather have Something|null 
in the return declaration than just in the docblock. That's all.




In a sense, if we really must allow for value-or-null (which I consider
a code smell in the 98% case) I'd prefer if it was ONLY available via
union types: That is, Something|null.  That's longer and clumsier to
type, and harder to read.  Which it should be. (Static casts in C++ have
a fugly syntax, which has been defended by the language designers on the
grounds that static casts are fugly, so the syntax for them should be as
well to remind you to stop doing it. There is a fair amount of validity
to that argument on affordance grounds, at least within C++.)  Using an
easy short hand notation for something that is inherently a code smell
when you're already typing your code only serves to encourage something
we should be training people out of in the first place.


With regard to syntax, I prefer the long form `Something|null`. That 
seems very clear to me. The proposed short-hand ? syntax always makes me 
think of what I hate most about regex.


Tom


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Levi Morrison]

> convinced by the rebuttles to change my mind.

s/rebuttles/rebuttals/

I thought about just letting it go like many typos/spelling mistakes
but it seemed too funny to not correct

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Levi Morrison]

> I'm not suggesting that we purge NULL from the language.  That's
> impractical/impossible. I'm suggesting we shouldn't soften the type system
> added in 7.0, which discourages its use in most cases, as it should be.

It is a common misconception I've heard several times now that union
types is weakening or softening the type system. I want to reiterate
that it is already possible to use multiple types. It is already done
in the wild. It is done all over our standard library. The union types
RFC just allows you to encode the specific types to be passed or
returned. In other words it is aiming to make using the dynamic types
of PHP safer by allowing you to explicitly write out the options.

The Nullable Return Types RFC is basically arguing that the only
useful union of types is `T | Null` and only for return types. I've
already stated a few of my concerns with that belief and have not been
convinced by the rebuttles to change my mind.

Also, to specifically address a concern Larry had earlier about
nullable types in general:

> I am highly, highly sceptical about nullable parameters or returns, and 
> frankly would rather they were not included in the language.

Just to clarify: we already have nullable parameters because of a
default of null. It's already in the language and people have asked
many times for this functionality to be expanded to include return
types. I should have kept a master list every time someone contacted
me on github, email, twitter, etc about this so I could easily list
them all as references in the relevant RFCs for demand for the
feature.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Larry Garfield]

On 4/15/16 4:55 AM, Lester Caine wrote:

On 15/04/16 05:22, Levi Morrison wrote:

Unless you like having is_null() scattered around your code in a hundred

places...  I don't. :-)

You have lots of code instead in exception handling away fro the normal
program flow?


[1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions

--Larry Garfield

My point is that `foo(bar(), $val)` won't die because bar may return
null. Bar is expected to return null sometimes.

For example, let's consider an administrator page where they look up
user information based on an identifier. The routine we'll use will
have this signature:

 function get_user(string $id): User | Null;

It is possible for an identifier to not exist and this is not an error
(database successfully returned no results). If there is no User data
to display then it makes sense for the UI to present that differently.
Thus it makes sense to pass that User | Null onto the code that will
present it:

 $user_data = get_user($id);
 // ...
 $user_html = render_user_data($user_data);

In fact this is a common operation that is encountered in many code
bases (I think every single one I've ever looked at).

That is a possible database type scenario, although on all of my
systems, the 'guest' user will be accessed as a default which gives the
default user data set.

The main thing I see with the 'null is not needed' argument is that it
instead relies on 'exception handling'? If I am scanning a file or
reading a record set, at some point I hit the end, and in ALL my code
base I get a null object rather than result object, be that reading and
processing a file or a database feed. We have already had the complaints
about file handling should give an exception when there is nothing left,
but MY workflow keeps everything in line ... when the last record is
processed we see the 'null' and progress to the next step in the
process. There is nothing here that needs to involve throwing exceptions
which may well be coded out of line with the main program flow and make
debugging more difficult?


That there are a few small cases where PHP's current design makes NULL a 
reasonable sentinel value (custom iterators, fread() as you mention, 
etc.) does not mean that in most cases, returning ValueObject|Null is 
rude and abusive to users of your API.  Yes, end-of-file is not an 
exceptional case so should not throw an exception.  I completely agree 
there.  But "user not found" I'd argue is.  (Or rather, if it's not an 
exceptional case your data model is kinda broken to begin with, because 
why are you asking for a missing user?)  Or you're better off having an 
"empty" value instead, such as an anonymous user object.  That's still 
type safe.


I'm not suggesting that we purge NULL from the language.  That's 
impractical/impossible. I'm suggesting we shouldn't soften the type 
system added in 7.0, which discourages its use in most cases, as it 
should be.


--
--Larry Garfield


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Lester Caine]

On 15/04/16 05:22, Levi Morrison wrote:
>> Unless you like having is_null() scattered around your code in a hundred
>> > places...  I don't. :-)
You have lots of code instead in exception handling away fro the normal
program flow?

>> > [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions
>> >
>> > --Larry Garfield
> My point is that `foo(bar(), $val)` won't die because bar may return
> null. Bar is expected to return null sometimes.
> 
> For example, let's consider an administrator page where they look up
> user information based on an identifier. The routine we'll use will
> have this signature:
> 
> function get_user(string $id): User | Null;
> 
> It is possible for an identifier to not exist and this is not an error
> (database successfully returned no results). If there is no User data
> to display then it makes sense for the UI to present that differently.
> Thus it makes sense to pass that User | Null onto the code that will
> present it:
> 
> $user_data = get_user($id);
> // ...
> $user_html = render_user_data($user_data);
> 
> In fact this is a common operation that is encountered in many code
> bases (I think every single one I've ever looked at).

That is a possible database type scenario, although on all of my
systems, the 'guest' user will be accessed as a default which gives the
default user data set.

The main thing I see with the 'null is not needed' argument is that it
instead relies on 'exception handling'? If I am scanning a file or
reading a record set, at some point I hit the end, and in ALL my code
base I get a null object rather than result object, be that reading and
processing a file or a database feed. We have already had the complaints
about file handling should give an exception when there is nothing left,
but MY workflow keeps everything in line ... when the last record is
processed we see the 'null' and progress to the next step in the
process. There is nothing here that needs to involve throwing exceptions
which may well be coded out of line with the main program flow and make
debugging more difficult?

-- 
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 Return Type Declaration

[Levi Morrison]

On Thu, Apr 14, 2016 at 6:48 PM, Larry Garfield  wrote:
> On 04/14/2016 07:33 PM, Tom Worster wrote:
>>
>> On 4/14/16, 5:46 PM, "Levi Morrison" > le...@php.net> wrote:
>>
>>> Having a separate method instead of `foo(null, "value")` makes it
>>> difficult to use for the result of a function.
>>
>> I suspect that might be a good thing:) I don't know for sure but the
>> possibility exists.
>>
>>
>>> Assume `bar()` returns
>>> `Bar | Null`; this would no longer work if they were separated:
>>>
>>> foo(bar(), "value")
>>>
>>> Functions are often composed so if something is the output of one
>>> function it will likely be the input to another. Thus if returning
>>> optionally null values is important to you so should optionally null
>>> parameters.
>>
>> This was a chin-scratcher for me. On one hand, I see what you mean. On the
>> other I couldn't think of an example from my experience (which I admit is
>> very narrow -- I live a sheltered life) of such a bar() that I would feed
>> straight foo().
>>
>> The semantic convention for Something or null return, as I see it, is when
>> bar() returns null, it is saying "I got nothing". What kind of foo() does
>> the same thing to nothing at all as it does to a Something object? This is
>> where I got stuck.
>>
>> Say I was doing the composition instead via chaining.
>> Something::bar()->foo("value") is nonsense if bar() could return null.
>> This suggests to me that the other composition might not be wise.
>>
>> *Either* bar() should not be returning Something or null (maybe it should
>> instead return some other type that can represent all the possible
>> returns) *or* we shouldn't try to compose like this and should test for
>> the Somethingness of bar()'s return before apply ->foo("value") or foo(…,
>> "value") to it. Or maybe this API needs an even more fundamental redesign.
>>
>> So, from my perspective, this might be an example of the limitation
>> nudging us to think harder about the design.
>>
>> Tom
>
>
> I have to agree with Tom.  if foo(bar(), $val) could die because bar() may
> return NULL, that's not an indication that foo() needs to accept NULL.  It's
> a sign that bar() should not be returning it in the first place. :-)
>
> I am highly, highly sceptical about nullable parameters or returns, and
> frankly would rather they were not included in the language.  By nature they
> undermine type safety.  At best, they indicate to all callers "*every* time
> you call this function, you MUST put is_null() around it or your program may
> fail randomly."  While that's better to know explicitly than not (which is
> the case for any untyped return, aka any PHP code pre-7.0), it would be
> better still to, well, not have to worry about that billion dollar
> mistake[1] cropping up in my code.
>
> In a sense, if we really must allow for value-or-null (which I consider a
> code smell in the 98% case) I'd prefer if it was ONLY available via union
> types: That is, Something|null.  That's longer and clumsier to type, and
> harder to read.  Which it should be. (Static casts in C++ have a fugly
> syntax, which has been defended by the language designers on the grounds
> that static casts are fugly, so the syntax for them should be as well to
> remind you to stop doing it. There is a fair amount of validity to that
> argument on affordance grounds, at least within C++.)  Using an easy short
> hand notation for something that is inherently a code smell when you're
> already typing your code only serves to encourage something we should be
> training people out of in the first place.
>
> Unless you like having is_null() scattered around your code in a hundred
> places...  I don't. :-)
>
> [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions
>
> --Larry Garfield

My point is that `foo(bar(), $val)` won't die because bar may return
null. Bar is expected to return null sometimes.

For example, let's consider an administrator page where they look up
user information based on an identifier. The routine we'll use will
have this signature:

function get_user(string $id): User | Null;

It is possible for an identifier to not exist and this is not an error
(database successfully returned no results). If there is no User data
to display then it makes sense for the UI to present that differently.
Thus it makes sense to pass that User | Null onto the code that will
present it:

$user_data = get_user($id);
// ...
$user_html = render_user_data($user_data);

In fact this is a common operation that is encountered in many code
bases (I think every single one I've ever looked at).

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Larry Garfield]

On 04/14/2016 07:33 PM, Tom Worster wrote:

On 4/14/16, 5:46 PM, "Levi Morrison"  wrote:


Having a separate method instead of `foo(null, "value")` makes it
difficult to use for the result of a function.

I suspect that might be a good thing:) I don't know for sure but the
possibility exists.



Assume `bar()` returns
`Bar | Null`; this would no longer work if they were separated:

foo(bar(), "value")

Functions are often composed so if something is the output of one
function it will likely be the input to another. Thus if returning
optionally null values is important to you so should optionally null
parameters.

This was a chin-scratcher for me. On one hand, I see what you mean. On the
other I couldn't think of an example from my experience (which I admit is
very narrow -- I live a sheltered life) of such a bar() that I would feed
straight foo().

The semantic convention for Something or null return, as I see it, is when
bar() returns null, it is saying "I got nothing". What kind of foo() does
the same thing to nothing at all as it does to a Something object? This is
where I got stuck.

Say I was doing the composition instead via chaining.
Something::bar()->foo("value") is nonsense if bar() could return null.
This suggests to me that the other composition might not be wise.

*Either* bar() should not be returning Something or null (maybe it should
instead return some other type that can represent all the possible
returns) *or* we shouldn't try to compose like this and should test for
the Somethingness of bar()'s return before apply ->foo("value") or foo(…,
"value") to it. Or maybe this API needs an even more fundamental redesign.

So, from my perspective, this might be an example of the limitation
nudging us to think harder about the design.

Tom


I have to agree with Tom.  if foo(bar(), $val) could die because bar() 
may return NULL, that's not an indication that foo() needs to accept 
NULL.  It's a sign that bar() should not be returning it in the first 
place. :-)


I am highly, highly sceptical about nullable parameters or returns, and 
frankly would rather they were not included in the language.  By nature 
they undermine type safety.  At best, they indicate to all callers 
"*every* time you call this function, you MUST put is_null() around it 
or your program may fail randomly."  While that's better to know 
explicitly than not (which is the case for any untyped return, aka any 
PHP code pre-7.0), it would be better still to, well, not have to worry 
about that billion dollar mistake[1] cropping up in my code.


In a sense, if we really must allow for value-or-null (which I consider 
a code smell in the 98% case) I'd prefer if it was ONLY available via 
union types: That is, Something|null.  That's longer and clumsier to 
type, and harder to read.  Which it should be. (Static casts in C++ have 
a fugly syntax, which has been defended by the language designers on the 
grounds that static casts are fugly, so the syntax for them should be as 
well to remind you to stop doing it. There is a fair amount of validity 
to that argument on affordance grounds, at least within C++.)  Using an 
easy short hand notation for something that is inherently a code smell 
when you're already typing your code only serves to encourage something 
we should be training people out of in the first place.


Unless you like having is_null() scattered around your code in a hundred 
places...  I don't. :-)


[1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

On 4/14/16, 5:46 PM, "Levi Morrison"  wrote:

>Having a separate method instead of `foo(null, "value")` makes it
>difficult to use for the result of a function.

I suspect that might be a good thing:) I don't know for sure but the
possibility exists.


>Assume `bar()` returns
>`Bar | Null`; this would no longer work if they were separated:
>
>foo(bar(), "value")
>
>Functions are often composed so if something is the output of one
>function it will likely be the input to another. Thus if returning
>optionally null values is important to you so should optionally null
>parameters.

This was a chin-scratcher for me. On one hand, I see what you mean. On the
other I couldn't think of an example from my experience (which I admit is
very narrow -- I live a sheltered life) of such a bar() that I would feed
straight foo().

The semantic convention for Something or null return, as I see it, is when
bar() returns null, it is saying "I got nothing". What kind of foo() does
the same thing to nothing at all as it does to a Something object? This is
where I got stuck.

Say I was doing the composition instead via chaining.
Something::bar()->foo("value") is nonsense if bar() could return null.
This suggests to me that the other composition might not be wise.

*Either* bar() should not be returning Something or null (maybe it should
instead return some other type that can represent all the possible
returns) *or* we shouldn't try to compose like this and should test for
the Somethingness of bar()'s return before apply ->foo("value") or foo(…,
"value") to it. Or maybe this API needs an even more fundamental redesign.

So, from my perspective, this might be an example of the limitation
nudging us to think harder about the design.

Tom



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Levi Morrison]

>>Why not allow nullable types on parameters to avoid that wonkiness
>>caused by default values of null?
>>
>>function foo(Bar | Null $b, $not_optional_param);
>>
>>This is much better.
>
> Yes but still a code smell to me. I'd need to know more about the
> programmer's intent for `foo(null, "value")`. It might be better to swap
> order, or change the method name, or add another method... Who knows? Need
> to take each case individually.

Having a separate method instead of `foo(null, "value")` makes it
difficult to use for the result of a function. Assume `bar()` returns
`Bar | Null`; this would no longer work if they were separated:

foo(bar(), "value")

Functions are often composed so if something is the output of one
function it will likely be the input to another. Thus if returning
optionally null values is important to you so should optionally null
parameters.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

On 4/14/16, 1:33 PM, "Fleshgrinder"  wrote:

>On 4/14/2016 6:35 PM, Levi Morrison wrote:
>>I can appreciate that you want only the restricted union with null.
>> However, I do not see the point of disallowing it for parameter types
>>
>My guess is that this RFC only wants to get it for return because it
>might be an easier vote?

Hi Richard,

That wasn't really my intent. I tried to set out my argument contra
nullable param type in the RFC and elaborate it in my answer to Levi,
which I hope you read.

My attitude to programming reversed since 10 years ago. I used to prefer
to have all the options and be allowed to exercise my judgement. But over
those years I had to remain responsible for most of my code, which led to
a blinding conversion. Now I am so acutely aware of how likely I am to
write bugs that I more often than not want the language to get smaller.

My sense is that nullable params won't turn out to be one of the good
parts, in the Crockford sense. Something|null return, otoh, is so
established as a convention I can't imagine getting away from it.


I'm aware that some people won't understand my point of view. If that's
still the case, ask again and I'll try a different answer.

Tom



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

On 4/14/16, 12:35 PM, "Levi Morrison"  wrote:

>I can appreciate that you want only the restricted union with null.
>However, I do not see the point of disallowing it for parameter types
>while allowing it for return types:
>
>function setLeft(Node $n = null) {
>$this->left = $n;
>$this->updateHeight();
>}
>
>Why disallow the explicit union with null here instead of the default
>parameter which does not exactly capture the desired semantics?
>Calling `$node->setLeft()` is just odd, almost as if it was a mistake.
>I would much prefer `$node->setLeft(null)` here. Basically, if we have
>a feature for return types that exactly matches the semantics that we
>occasionally want for the parameter types why forbid it?

I agree that `$node->setLeft()` is weird but I find `$node->setLeft(null)`
still a bit weird. Perhaps something like `$node->resetLeft()` would work?
Was that the idea?


>Additionally, on occasion I'll see functions like this:
>
>function foo(Bar $b = null, $not_optional_param);

The only thing we can know for sure from this is that the programmer
urgently needs reeducation :)


>Why not allow nullable types on parameters to avoid that wonkiness
>caused by default values of null?
>
>function foo(Bar | Null $b, $not_optional_param);
>
>This is much better.

Yes but still a code smell to me. I'd need to know more about the
programmer's intent for `foo(null, "value")`. It might be better to swap
order, or change the method name, or add another method... Who knows? Need
to take each case individually.

This kind of asking questions about intent in code review is good for code
quality. That's why I like how PHP doesn't allow this. It encourages the
question asking. Every case is different, of course, so you can surely
find counter examples. But on balance I'd say it's better to disallow it.


Does this help you understand my preference? I think the restriction
encourages a healthy discipline.

Otoh, I think nullable return is a pressing need.

Tom



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Fleshgrinder]

On 4/14/2016 6:35 PM, Levi Morrison wrote:
> On Thu, Apr 14, 2016 at 9:39 AM, Tom Worster  wrote:
>> I would like to introduce for discussion an RFC proposing and arguing for
>> Nullable Return Type Declaration in 7.1 and deferring for now more general
>> relaxations of 7.0 type as proposed in Levi's two RFCs.
>>
>>   https://wiki.php.net/rfc/nullable_returns
>>
>> If anyone would like to collaborate on the RFC, I have a repo you may fork:
>> https://gist.github.com/tom--/e95a10fbe4d34f8a72c9 (although guthub's
>> formatting isn't lovely). I'm looking for help with implementation.
>>
>> Tom
>>
>>
>>
> 
> I can appreciate that you want only the restricted union with null.
> However, I do not see the point of disallowing it for parameter types
> while allowing it for return types:
> 
> function setLeft(Node $n = null) {
> $this->left = $n;
> $this->updateHeight();
> }
> 
> Why disallow the explicit union with null here instead of the default
> parameter which does not exactly capture the desired semantics?
> Calling `$node->setLeft()` is just odd, almost as if it was a mistake.
> I would much prefer `$node->setLeft(null)` here. Basically, if we have
> a feature for return types that exactly matches the semantics that we
> occasionally want for the parameter types why forbid it?
> 
> Additionally, on occasion I'll see functions like this:
> 
> function foo(Bar $b = null, $not_optional_param);
> 
> Why not allow nullable types on parameters to avoid that wonkiness
> caused by default values of null?
> 
> function foo(Bar | Null $b, $not_optional_param);
> 
> This is much better.
> 

My guess is that this RFC only wants to get it for return because it
might be an easier vote?

I do not like the fact that only the long version of union types is
supported and prefer the question mark approach as a short hand. Can
this RFC be either extended to include that as well or removed so it
does not get in the way of the other two RFCs?

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Levi Morrison]

On Thu, Apr 14, 2016 at 9:39 AM, Tom Worster  wrote:
> I would like to introduce for discussion an RFC proposing and arguing for
> Nullable Return Type Declaration in 7.1 and deferring for now more general
> relaxations of 7.0 type as proposed in Levi's two RFCs.
>
>   https://wiki.php.net/rfc/nullable_returns
>
> If anyone would like to collaborate on the RFC, I have a repo you may fork:
> https://gist.github.com/tom--/e95a10fbe4d34f8a72c9 (although guthub's
> formatting isn't lovely). I'm looking for help with implementation.
>
> Tom
>
>
>

I can appreciate that you want only the restricted union with null.
However, I do not see the point of disallowing it for parameter types
while allowing it for return types:

function setLeft(Node $n = null) {
$this->left = $n;
$this->updateHeight();
}

Why disallow the explicit union with null here instead of the default
parameter which does not exactly capture the desired semantics?
Calling `$node->setLeft()` is just odd, almost as if it was a mistake.
I would much prefer `$node->setLeft(null)` here. Basically, if we have
a feature for return types that exactly matches the semantics that we
occasionally want for the parameter types why forbid it?

Additionally, on occasion I'll see functions like this:

function foo(Bar $b = null, $not_optional_param);

Why not allow nullable types on parameters to avoid that wonkiness
caused by default values of null?

function foo(Bar | Null $b, $not_optional_param);

This is much better.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

I would like to introduce for discussion an RFC proposing and arguing for
Nullable Return Type Declaration in 7.1 and deferring for now more general
relaxations of 7.0 type as proposed in Levi's two RFCs.

  https://wiki.php.net/rfc/nullable_returns

If anyone would like to collaborate on the RFC, I have a repo you may fork:
https://gist.github.com/tom--/e95a10fbe4d34f8a72c9 (although guthub's
formatting isn't lovely). I'm looking for help with implementation.

Tom

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Derick Rethans]

On Thu, 15 Oct 2015, Rowan Collins wrote:

> Korvin Szanto wrote on 14/10/2015 23:55:
> > If I capture the result of a "void" method and check if my result variable
> > with isset(), I'll get false. This sounds like it's void of value to me.
> 
> But why "invent" (as far as PHP is concerned) this new keyword of "void" to
> mean exactly the same thing "null" already means - absence of a definite
> value?

It's already "invented" for PHP anyway: 
http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example 
2.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Bob Weinand]

> Am 19.10.2015 um 11:46 schrieb Derick Rethans :
> 
> On Thu, 15 Oct 2015, Rowan Collins wrote:
> 
>> Korvin Szanto wrote on 14/10/2015 23:55:
>>> If I capture the result of a "void" method and check if my result variable
>>> with isset(), I'll get false. This sounds like it's void of value to me.
>> 
>> But why "invent" (as far as PHP is concerned) this new keyword of "void" to
>> mean exactly the same thing "null" already means - absence of a definite
>> value?
> 
> It's already "invented" for PHP anyway: 
> http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example 
> 2.
> 
> cheers,
> Derick

When something is "invented" in Hack, … How is that related to PHP?
Hack is a language where a major equal subset is same as in PHP, yes. But 
that's still not a reason to say it were "invented" for PHP.

Please do not use Hack as ultima ratio here, it just is one language like C, 
Java etc. which happens to have more in common with PHP than most. But it still 
is just one other language. It's not PHP.

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Lester Caine]

On 16/10/15 01:45, Andrea Faulds wrote:
> But why should we change the documentation anyway? We've used void for a
> very long time, at least 17 years[0]. We don't just use it in the PHP
> manual, it's also used in docblocks and the PHP source code's function
> prototypes. It's the commonly-accepted, widely-used term. Until now this
> was uncontroversial.

This are in my book is just the same as 'NULL'. Different styles of
working have different views on how things are interpreted. The function
sets for arrays as originally designed simply modified the target object
without returning any error code or similar value. The 'more modern' way
of doing this may be perhaps to 'return' the array? Or perhaps a count
of the number of elements moved - 0 indicates that nothing has changed.
I can see the reason you want the run time engine to flag an error if I
do $res = sort(xxx); but like many of the 'checks' that seem to be
bloating the run time code, I still see that as a function for a good
IDE rather than a run time error. void is just a documentational flag
that CURRENTLY there is nothing to return, but does not prevent a
modified version that may return a value at some point in the future.

What is 'controversial' is a change from the freedom of the user to
create code the way they want to work, which may wrap a void function in
a return check simply because at some point in the future they plan to
upgrade the simple off the shelf function call with something which
generates the return. I find enforced typing in the same bucket since
while some returns may clearly be 'integer' in other cases a later
development might use the fractional part for some other purpose. Others
seem to think that is bad practice? Having now two different styles of
working is something we simply now have to put up with, but loading the
bias even more in the direction of 'I think that you are wrong' needs to
have a very good case?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Andrea Faulds wrote on 14/10/2015 22:52:

Good evening,

I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!


My feeling is that it is odd to have both of these be true at once:

- void functions can appear in expressions, where the return value is 
interpreted as null

- "return;" and "return null;" are no longer treated as equivalent

If the intent is to say "you can use this in an expression, but its 
value will always be null so there's no point", then "return null;" 
seems just as valid as "return;", and a typehint of "null" seems to make 
more sense.


I take the point about making intent clear, but can't think of any other 
interpretation of "this function always returns null" than "this 
function has no meaningful result".  In other words, I can't imagine 
ever wanting to use "null" to mean something different from "void" in 
this context.



I can see the point in denying the right to say "return 
some_function_expected_to_return_null();" But in a sense this is no 
different from declaring that a function returns int, and then writing 
"return some_function_expected_to_return_int();"


If a void function can be used in an expression, it can be used in a 
return expression, and if so, it feels natural for the type hint to 
propagate:


function foo(): void { do_something(); }
function wrapped_foo(): void { do_something_else(); return foo(); }
// ERROR: can't specify return value in a void function

"return foo()" is not illegal because foo is declared void, but because 
wrapped_foo is - even though the result is exactly as expected.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Chris Riley]

On 14 October 2015 at 22:52, Andrea Faulds  wrote:

> Good evening,
>
> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
>
> https://wiki.php.net/rfc/void_return_type
>
> Please read it and tell me your thoughts!
>
> Thanks.
>
> P.S. As it so (fatefully?) happens, I originally introduced this on 14th
> February, and it's now 14th October, so it's been exactly 8 months!
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi,

Semantically, I don't believe that there is sufficient difference between
"returns no value" and "returns a value which has been defined as having no
value" for us to care about it. The main difference you get between return
type of null and a return type of void seems to be some extra fatal errors,
for a developer there seems little value.

>From a user confusion point of view; PHP currently considers return; and
return null; to be equivalent (in fact some code style checkers will
replace one with the other) If (and only if) a function has a return type
of void these two statements are no longer equivalent - one is a fatal
error one is not. For any other return type specification, return null; and
return; would behave the same. This in itself would be enough for me to be
against adding a return type of void.

(also could someone enable my wiki acc: carnage; sent an email ~a week ago
and haven't heard back yet :()

~C

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Björn Larsson]

Den 2015-10-14 kl. 23:52, skrev Andrea Faulds:

Good evening,

I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!

Thanks.

P.S. As it so (fatefully?) happens, I originally introduced this on 
14th February, and it's now 14th October, so it's been exactly 8 months!



Thanks! I have been waiting for this RFC to reopen. Actually
wondered why void wasn't among the reserved words in the
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7.

Regards //Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Korvin Szanto wrote on 14/10/2015 23:55:

If I capture the result of a "void" method and check if my result variable
with isset(), I'll get false. This sounds like it's void of value to me.


But why "invent" (as far as PHP is concerned) this new keyword of "void" 
to mean exactly the same thing "null" already means - absence of a 
definite value?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Andrea Faulds wrote on 15/10/2015 16:32:
Hmm, this is an interesting case you've pointed out. Being able to do 
`return some_other_void_function();` is something I've desired in 
other languages.


But what if that void function you're calling later adds a return 
value? Now the calling function is returning a value other than null, 
violating its type hint and producing a runtime error.


Well, fundamentally, this is true of anything short of full 
type-checking. The type safety below is self-evident:


function foo(): int { return 42; }
function wrapped_foo(): int { return foo(); }

But foo() could later be changed to this:

function foo(): string { return 'The Answer'; }

The wrapped_foo() typehint is now broken. That's not really any 
different from foo() starting off as void/returns-null and adding a 
return value.


In both cases, a static analyser could detect the discrepancy, but the 
Zend Engine will not, until the function is executed.



It's a shame there's no "tail call this other function and discard its 
result" construct. 


Yeah, I guess what you really want is for a void function to be able to 
"goto foo();"


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Rowan,

Rowan Collins wrote:

I can see the point in denying the right to say "return
some_function_expected_to_return_null();" But in a sense this is no
different from declaring that a function returns int, and then writing
"return some_function_expected_to_return_int();"

If a void function can be used in an expression, it can be used in a
return expression, and if so, it feels natural for the type hint to
propagate:

function foo(): void { do_something(); }
function wrapped_foo(): void { do_something_else(); return foo(); }
// ERROR: can't specify return value in a void function

"return foo()" is not illegal because foo is declared void, but because
wrapped_foo is - even though the result is exactly as expected.


Hmm, this is an interesting case you've pointed out. Being able to do 
`return some_other_void_function();` is something I've desired in other 
languages.


But what if that void function you're calling later adds a return value? 
Now the calling function is returning a value other than null, violating 
its type hint and producing a runtime error.


It's a shame there's no "tail call this other function and discard its 
result" construct.


Thanks.


--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Andrea Faulds wrote on 15/10/2015 16:32:

Hi Rowan,

Rowan Collins wrote:

But why "invent" (as far as PHP is concerned) this new keyword of "void"
to mean exactly the same thing "null" already means - absence of a
definite value?


They don't mean exactly the same thing. null is a value to represent a 
lack of a value. But there's also the concept of *no value at all* (a 
missing variable, say). The closest we have to that in PHP already 
would actually be `unset`, but that's a strange choice given it's not 
what we use in documentation (function prototypes, PHP manual, PHPDoc, 
etc. use `void`), and it's tainted by the bizarro `(unset)` cast which 
casts to null. 


Oh, lord, not this discussion again! PHP has no concept of a variable 
being in the "state" of unset; it has programmer hints to warn you if 
you read before writing, and a couple of odd constructs which let you 
access the current symbol table as a dictionary.


The manual has some weird wording in places which implies that a 
variable takes on a type when first used, but in practice the rule is 
much simpler: any variable which hasn't had a value assigned yet is 
considered to have the value NULL, and normal cast rules apply from 
there. The same is true of missing array keys, object properties, 
unset() variables, unspecified return values, etc, etc, etc. They are 
all NULL.


You could add a warning for "function foo() { return; } $a = foo();" to 
match "$x = []; $a = $x['foo'];", but $a would still unambiguously 
contain the value NULL in both cases, and outside of some odd 
applications like templating, it is *values* the program should be 
concerned with, not the *reason* for those values.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Rowan,

Rowan Collins wrote:

But why "invent" (as far as PHP is concerned) this new keyword of "void"
to mean exactly the same thing "null" already means - absence of a
definite value?


They don't mean exactly the same thing. null is a value to represent a 
lack of a value. But there's also the concept of *no value at all* (a 
missing variable, say). The closest we have to that in PHP already would 
actually be `unset`, but that's a strange choice given it's not what we 
use in documentation (function prototypes, PHP manual, PHPDoc, etc. use 
`void`), and it's tainted by the bizarro `(unset)` cast which casts to null.


Thanks.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Pedro Cordeiro]

I've been thinking about what PHP should do when accessing the return value
of a `void` function, and so far, I think the consistent thing should be to
get NULL, while throwing an E_NOTICE.

$a = $b; //$b wasn't initiated.

This does the same thing. I tried accessing what was supposed to be
'nothing' ($b), and got NULL with an E_NOTICE being thrown.

function myFunc() : void { ... }
$a = myFunc();

I see no reason why this should silently assign NULL to $a, *specially* with
"return null;" being explicitly forbidden.

My point is: we already use an implicit NULL return on functions with
missing return values (or with "return ;"), but now we're explicitly
prohibiting even a NULL return. The behaviour should be consistent (NULL
should be accessed, as for all undefined things), with an E_NOTICE.

function myFunc() { return ; }
$a = myFunc();

Should assign NULL to $a and *not* throw an E_NOTICE (this is the current
status), because a return type was not forbidden with the keyword 'void'.

2015-10-15 13:00 GMT-03:00 Rowan Collins :

> Andrea Faulds wrote on 15/10/2015 16:32:
>
>> Hmm, this is an interesting case you've pointed out. Being able to do
>> `return some_other_void_function();` is something I've desired in other
>> languages.
>>
>> But what if that void function you're calling later adds a return value?
>> Now the calling function is returning a value other than null, violating
>> its type hint and producing a runtime error.
>>
>
> Well, fundamentally, this is true of anything short of full type-checking.
> The type safety below is self-evident:
>
> function foo(): int { return 42; }
> function wrapped_foo(): int { return foo(); }
>
> But foo() could later be changed to this:
>
> function foo(): string { return 'The Answer'; }
>
> The wrapped_foo() typehint is now broken. That's not really any different
> from foo() starting off as void/returns-null and adding a return value.
>
> In both cases, a static analyser could detect the discrepancy, but the
> Zend Engine will not, until the function is executed.
>
>
> It's a shame there's no "tail call this other function and discard its
>> result" construct.
>>
>
> Yeah, I guess what you really want is for a void function to be able to
> "goto foo();"
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hey Chris,

Chris Riley wrote:

Semantically, I don't believe that there is sufficient difference between
"returns no value" and "returns a value which has been defined as having no
value" for us to care about it. The main difference you get between return
type of null and a return type of void seems to be some extra fatal errors,
for a developer there seems little value.

 From a user confusion point of view; PHP currently considers return; and
return null; to be equivalent (in fact some code style checkers will
replace one with the other) If (and only if) a function has a return type
of void these two statements are no longer equivalent - one is a fatal
error one is not. For any other return type specification, return null; and
return; would behave the same. This in itself would be enough for me to be
against adding a return type of void.


This is true, but `void` isn't an ordinary return type. It exists to 
ensure a function doesn't return anything, unlike other return types 
which exist to ensure a function returns a specific thing.


`return null;` is *technically* equivalent to `return;`, but it's not 
quite the same in intent, usually. We could special-case it and allow 
it, but why? The return value isn't supposed to be used, why should we 
allow you to specify it? A void function in PHP does technically produce 
a result of null, but it might as well be false or -1 or whatever for 
all we care. Also, if `return null;` is to work, should `return(null);` 
also work? How about `return \null;`? `return SOME_NULL_CONSTANT;`? It 
seems silly to me since, again, the return value is insigificant.


Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Larry,

Larry Garfield wrote:

On 10/14/2015 06:30 PM, Andrea Faulds wrote:

This would be strange. The manual doesn't say `null`, and I can't
think of any language which uses `null` as the return type in this
situation, even when they have the same implicit-null-return behaviour
that PHP has (see the email you're replying to).

Also, wouldn't you expect this to behave like existing type hints, and
let you return a null value from any source? But that's not what you
would actually want, right?

Thanks.


Well, that depends on the intent here.  In practice, is the intent to
add a "no return at all" type of function (ie, $a = foo() is a syntax
error now where it was not before), or to make it explicit that the only
legal return is null (even if implicitly that means having a non-early
return statement is pointless)?  Those are the two options.  That may or
may not dictate the keyword that gets used.


It would seem ideal to have "true" void functions which can't be used as 
expressions, i.e. producing an error if you try to use them like in your 
example. But they'd cause a backwards-compatibility headache, and I'm 
not sure they're a good idea anyway. Every function call being an 
expression is pretty handy. You can safely capture the return value of a 
callback and pass it along, for instance.


In a sense, what this RFC offers might be called a compromise. It 
enforces the rules of `void` within the function, but at the end of the 
day the caller still gets a null out of it since that's what PHP's 
always done.



It definitely sounds like you're favoring the second (as that's what the
RFC says).  Which may or make not make "void" an odd keyword to choose
when what's actually happening is NULL getting returned.  Is NULL a
void?  (There's a deep philosophical question...)


It's an interesting question. There's some precedent for using `void` in 
this way even though the functions aren't "truly" void. I mostly like 
`void` because it's the customary keyword to use, though. Everyone knows 
what a 'void function' is.



As I said, I don't have a strong opinion on the subject yet.  I'm just
trying to distil the discussion down to as small a question as possible.
:-)


I appreciate your efforts. I have a tendency to be a bit verbose in my 
writing, so providing clarity is helpful. :)


Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Marc Bennewitz]

On 10/15/2015 01:19 AM, Larry Garfield wrote:
On 10/14/2015 06:00 PM, Andrea Faulds wrote:  >> Both you and Stas have said this, but it's only true if we solely 
>> consider C-like languages. Other languages do different things. In 
>> the PHP manual, Hack, TypeScript, ActionScript, and most likely 
other >> languages (these are just off the top of my head), `void` 
functions >> do still have an implicit result. >> >> All of these 
languages would have had the choice to do what you're >> suggesting and 
use `null`, or its equivalent (`undefined` for >> TypeScript and 
ActionScript). They didn't. Why? If I had to guess, >> there's at least 
three reasons. For one, void is the word languages >> usually use for 
this. For another, `void` and `null` they mean >> different things. 
`void` signifies a function isn't returning >> anything. `null` 
signifies a function that *returns null*, regardless >> of where that 
null came from. `function foo(): null { return >> 
some_probably_null_returning_function(); }` should surely be legal >> 
with a `null` type hint, yet it's nonsensical code. Finally, making a >> 
function truly "return nothing", i.e. disallowing its use as an >> 
expression/rvalue, breaks some use cases, like passing along the >> 
result of a callback. >> >> PHP would neither be the first nor the last 
to be using `void` in >> this way. >> >>> If the union types RFC[2] 
passes it >>> makes sense to allow `Foo | null` which allows something 
of type `Foo` >>> or `null`. To me it makes sense that if you then 
remove `Foo` you are >>> left with `null`, not `void`. My personal 
recommendation because of >>> this would be to use `null` for the return 
type and instead of `void`. >> >> `null` would be a weird type, because 
it doesn't make sense as a >> parameter type, and as a return type, you 
don't really want to >> enforce returning null, you want to enforce not 
returning at all (see >> the example above). It feels like a poor man's 
substitute to me. >> >> Thanks. > > The tricky part here is that saying 
a function does not return is not > something PHP currently does: > > 
https://3v4l.org/HtAuC > > No return implicitly returns NULL, which you 
can assign to a variable > if, for some strange reason, you were so 
inclined. So this would be > more than "just" a syntactic documentation 
feature. > > Which I believe gives the following options: > > 1) Change 
the language behavior such that > > function foo() : void { ...} > $a = 
foo(); > > Is a syntax error (because there really was nothing returned 
to > assign), rather than resulting in $a having a value of NULL. > > 2) 
Use null as a "type" (which I agree feels weird just saying it), > such 
that: > > function foo() : null { ...} > $a = foo(); > > and > > 
function foo() { ...} > $a = foo(); > > are identical. The former would 
impact the contents of the function > (eg, a non-empty return would be a 
parse error), but the external > result is the same ($a == NULL). > > 3) 
Use the "void" keyword, but give it the same effect as option 2. > > The 
RFC currently seems to propose option 3 (based on the "Use of void > 
functions in expressions" section). I don't have a strong feeling at > 
this point about which option I'd prefer. >

Option 4)

// implicit return void
function foo () { return; }

// explicit return void
function foo () : void { return; };

// syntax error if returning something on explicit return void
function foo () : void { return null; };

// syntax error on using return value of explicit return void
function foo () : void { return; };
$bar = foo();

// return NULL on implicit return void (this could also give a 
warning/notice/deprecated error)

function foo () { return; };
$bar = foo(); // NULL

// mixing return void with any other return values could also result in 
a warning/notice/deprecated error

function foo () { if ($bar) return; return $bar; };


--Larry Garfield  >


I really like this as in my opinion if a function doesn't return 
something it should be part of the function signature and it really 
helps to avoid mistakes on writing code.


Marc

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

On 15 October 2015 20:33:04 BST, Andrea Faulds  wrote:
>> Obviously, type hints for internal functions are a bit weird anyway,
>but
>> there's no reason to assume that every function documented as void
>would
>> suddenly be annotated in the Engine as such and start returning
>notices.
>
>Why shouldn't it? For the scalar types, internal and userland functions behave 
>almost the same.

Just for the same reason that an existing function that uses bare "return;" 
won't automatically be considered "void" - nobody has  explicitly decided that 
that's the intent.

Sure, internal functions whose value shouldn't be used *could* be marked void, 
and those would start raising Notices if that was part of void's behaviour. But 
there would only be a blizzard of Notices if someone bulk updated every 
function in core which happens to return null, which doesn't seem like an 
automatic part of creating a void return behaviour.  Especially if the whole 
point is that "void" signifies something more than "always returns null".

Since it's been mentioned a couple of times, I'd like to say that although the 
documentation is official, I think it should be considered descriptive not 
prescriptive - if it labels something as void, but the Engine doesn't consider 
it so, the manual would be wrong, not the Engine.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Korvin Szanto]

On Thu, Oct 15, 2015 at 4:21 PM Rowan Collins 
wrote:

> On 15 October 2015 20:33:04 BST, Andrea Faulds  wrote:
> >> Obviously, type hints for internal functions are a bit weird anyway,
> >but
> >> there's no reason to assume that every function documented as void
> >would
> >> suddenly be annotated in the Engine as such and start returning
> >notices.
> >
> >Why shouldn't it? For the scalar types, internal and userland functions
> behave almost the same.
>
> Just for the same reason that an existing function that uses bare
> "return;" won't automatically be considered "void" - nobody has  explicitly
> decided that that's the intent.
>
> Sure, internal functions whose value shouldn't be used *could* be marked
> void, and those would start raising Notices if that was part of void's
> behaviour. But there would only be a blizzard of Notices if someone bulk
> updated every function in core which happens to return null, which doesn't
> seem like an automatic part of creating a void return behaviour.
> Especially if the whole point is that "void" signifies something more than
> "always returns null".
>
> Since it's been mentioned a couple of times, I'd like to say that although
> the documentation is official, I think it should be considered descriptive
> not prescriptive - if it labels something as void, but the Engine doesn't
> consider it so, the manual would be wrong, not the Engine.
>

Could we change the documentation for existing functions to return null,
and start using void properly moving forward?

Thanks,
Korvin

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Korvin,

Korvin Szanto wrote:


Could we change the documentation for existing functions to return null,
and start using void properly moving forward?



As I have stated several times now, we're not "misusing" void. PHP is 
not the only language to use the word in this manner.


But why should we change the documentation anyway? We've used void for a 
very long time, at least 17 years[0]. We don't just use it in the PHP 
manual, it's also used in docblocks and the PHP source code's function 
prototypes. It's the commonly-accepted, widely-used term. Until now this 
was uncontroversial.


Why should we move heaven and earth when there's nothing wrong?

[0] 
https://web.archive.org/web/19991002011107/http://php.net/manual/function.sort.php3



--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hey Chris,

Chris Riley wrote:

Semantically, I don't believe that there is sufficient difference between
"returns no value" and "returns a value which has been defined as having no
value" for us to care about it. The main difference you get between return
type of null and a return type of void seems to be some extra fatal errors,
for a developer there seems little value.

 From a user confusion point of view; PHP currently considers return; and
return null; to be equivalent (in fact some code style checkers will
replace one with the other) If (and only if) a function has a return type
of void these two statements are no longer equivalent - one is a fatal
error one is not. For any other return type specification, return null; and
return; would behave the same. This in itself would be enough for me to be
against adding a return type of void.


This is true, but `void` isn't an ordinary return type. It exists to 
ensure a function doesn't return anything, unlike other return types 
which exist to ensure a function returns a specific thing.


`return null;` is *technically* equivalent to `return;`, but it's not 
quite the same in intent, usually. We could special-case it and allow 
it, but why? The return value isn't supposed to be used, why should we 
allow you to specify it? A void function in PHP does technically produce 
a result of null, but it might as well be false or -1 or whatever for 
all we care. Also, if `return null;` is to work, should `return(null);` 
also work? How about `return \null;`? `return SOME_NULL_CONSTANT;`? It 
seems silly to me since, again, the return value is insigificant.


Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Pedro,

Pedro Cordeiro wrote:

I've been thinking about what PHP should do when accessing the return value
of a `void` function, and so far, I think the consistent thing should be to
get NULL, while throwing an E_NOTICE.


We could do this, but I do wonder if it might cause a lot of E_NOTICEs 
to pop up for existing code, assuming we applied this to built-in PHP 
functions.


I'm not sure.

Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Chris Riley]

On 15 October 2015 at 16:32, Andrea Faulds  wrote:


> In a sense, what this RFC offers might be called a compromise. It enforces
> the rules of `void` within the function, but at the end of the day the
> caller still gets a null out of it since that's what PHP's always done.
>
>
>
If this truly is the case, then all you get over hinting void as the return
type instead of null is a fatal error for return null; Sure you can argue
for capturing intent but realistically the difference in intent between
'returns no value' and 'does not return a value' is something for
philosophers to argue over not programmers. ;)

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Pedro Cordeiro]

>
> this would make the "void" keyword feel more meaningful.


I, too, had issues trying to understand what "void" was bringing to the
table. IMHO, it should warn people thinking some specific function/method
returns a value when it doesn't, not protect against some dev forgetting
the function he's writing should not return something.

IMHO, it's far more important to warn "Hey, this function returns NOTHING,
don't try to use its value because it doesn't exist!" then it is to warn
"Hey, this function can't return anything, stop trying to return things!".

Throwing an E_NOTICE when accessing a void return value would make perfect
sense, as the compiler would strict check that the function author defined
a no-return and indeed returned nothing and would also warn whoever was
calling the function that it doesn't return anything.

> We could do this, but I do wonder if it might cause a lot of E_NOTICEs to
pop up for existing code, assuming we applied this to built-in PHP
functions.

My proposal is to only throw an E_NOTICE when accessing a return value from
a function that is explicitly marked with "void". A function with no return
("return ;") but with no ": void" on the signature would not necessarily
throw an E_NOTICE.

function myFunc() { return ; }
$a = myFunc(); //NULL should be assigned to $a silently, like it is today.
function myOtherFunc() : void { return ; }
$b = myOtherFunc(); //NULL should be assigned to $b, but an E_NOTICE is
thrown.

2015-10-15 13:34 GMT-03:00 Andrea Faulds :

> Hi Pedro,
>
> Pedro Cordeiro wrote:
>
>> I've been thinking about what PHP should do when accessing the return
>> value
>> of a `void` function, and so far, I think the consistent thing should be
>> to
>> get NULL, while throwing an E_NOTICE.
>>
>
> We could do this, but I do wonder if it might cause a lot of E_NOTICEs to
> pop up for existing code, assuming we applied this to built-in PHP
> functions.
>
> I'm not sure.
>
> Thanks.
> --
> Andrea Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Pedro Cordeiro wrote on 15/10/2015 17:14:
I've been thinking about what PHP should do when accessing the return 
value of a `void` function, and so far, I think the consistent thing 
should be to get NULL, while throwing an E_NOTICE.


$a = $b; //$b wasn't initiated.

This does the same thing. I tried accessing what was supposed to be 
'nothing' ($b), and got NULL with an E_NOTICE being thrown.


function myFunc() : void { ... }
$a = myFunc();

I see no reason why this should silently assign NULL to $a, 
*specially* with "return null;" being explicitly forbidden. ... The 
behaviour should be consistent (NULL should be accessed, as for all 
undefined things), with an E_NOTICE.


I don't know how easy this would be to implement, but I agree that this 
would make the "void" keyword feel more meaningful.


Does the Engine have a way to know whether a return value is being used 
or discarded for optimisation purposes? If so, could that logic be 
hooked to provide the Notice?


Regards,
--
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Rowan Collins]

Andrea Faulds wrote on 15/10/2015 17:34:

Hi Pedro,

Pedro Cordeiro wrote:
I've been thinking about what PHP should do when accessing the return 
value
of a `void` function, and so far, I think the consistent thing should 
be to

get NULL, while throwing an E_NOTICE.


We could do this, but I do wonder if it might cause a lot of E_NOTICEs 
to pop up for existing code, assuming we applied this to built-in PHP 
functions.


I'm not sure. 



The way Pedro described it, it wouldn't apply to any existing functions 
because they wouldn't be declared void.


Obviously, type hints for internal functions are a bit weird anyway, but 
there's no reason to assume that every function documented as void would 
suddenly be annotated in the Engine as such and start returning notices.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Björn Larsson]

Den 2015-10-15 kl. 09:04, skrev Björn Larsson:

Den 2015-10-14 kl. 23:52, skrev Andrea Faulds:

Good evening,

I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!

Thanks.

P.S. As it so (fatefully?) happens, I originally introduced this on 
14th February, and it's now 14th October, so it's been exactly 8 months!



Thanks! I have been waiting for this RFC to reopen. Actually
wondered why void wasn't among the reserved words in the
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7.

Regards //Björn


Hm... Just noticed that HACK allows void as return type. Wonder
how it works and motivation for having it? Mention in RFC?

//Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Rowan,

Rowan Collins wrote:

Andrea Faulds wrote on 15/10/2015 17:34:

Hi Pedro,

Pedro Cordeiro wrote:

I've been thinking about what PHP should do when accessing the return
value
of a `void` function, and so far, I think the consistent thing should
be to
get NULL, while throwing an E_NOTICE.


We could do this, but I do wonder if it might cause a lot of E_NOTICEs
to pop up for existing code, assuming we applied this to built-in PHP
functions.

I'm not sure.



The way Pedro described it, it wouldn't apply to any existing functions
because they wouldn't be declared void.

Obviously, type hints for internal functions are a bit weird anyway, but
there's no reason to assume that every function documented as void would
suddenly be annotated in the Engine as such and start returning notices.


Why shouldn't it? For the scalar types, internal and userland functions 
behave almost the same.


I'd like there the two to converge, not diverge.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Ryan Pallas]

On Wed, Oct 14, 2015 at 4:46 PM, Levi Morrison  wrote:
>
>
> I agree that `void` doesn't make sense given that we document that
> `return;` will return null[1].  If the union types RFC[2] passes it
> makes sense to allow `Foo | null` which allows something of type `Foo`
> or `null`. To me it makes sense that if you then remove `Foo` you are
> left with `null`, not `void`. My personal recommendation because of
> this would be to use `null` for the return type and instead of `void`.
>
> Also, I do not think this feature is pointless. For instance, it has
> value in interfaces. Declaring that a method does not return a value
> means implementors cannot accidentally return something. This is
> better than just documenting that it should not be done.


+1 these are my thoughts exactly. I would be for it if it was null, and
interfaces is exactly why I would be for it.

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Stanislav Malyshev]

Hi!

> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
> 
> https://wiki.php.net/rfc/void_return_type
> 
> Please read it and tell me your thoughts!

I still see no point in this, as every PHP function actually returns
something (at least null). So this type would not actually be right and
would not reflect what actually is happening.

Moreover, I don't see any scenario where some code depends on a function
not returning something explicitly (i.e. does not use return value) but
function actually returns something explicitly and the calling code
breaks. This appears to be impossible, and thus there's no reason to
declare a function "void" except purely for documentation purposes.
Adding keywords to the language just to document this does not look to
me like a good idea.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Levi,

Levi Morrison wrote:

On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev  wrote:

Hi!


I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!


I still see no point in this, as every PHP function actually returns
something (at least null). So this type would not actually be right and
would not reflect what actually is happening.


I agree that `void` doesn't make sense given that we document that
`return;` will return null[1].


Both you and Stas have said this, but it's only true if we solely 
consider C-like languages. Other languages do different things. In the 
PHP manual, Hack, TypeScript, ActionScript, and most likely other 
languages (these are just off the top of my head), `void` functions do 
still have an implicit result.


All of these languages would have had the choice to do what you're 
suggesting and use `null`, or its equivalent (`undefined` for TypeScript 
and ActionScript). They didn't. Why? If I had to guess, there's at least 
three reasons. For one, void is the word languages usually use for this. 
For another, `void` and `null` they mean different things. `void` 
signifies a function isn't returning anything. `null` signifies a 
function that *returns null*, regardless of where that null came from. 
`function foo(): null { return some_probably_null_returning_function(); 
}` should surely be legal with a `null` type hint, yet it's nonsensical 
code. Finally, making a function truly "return nothing", i.e. 
disallowing its use as an expression/rvalue, breaks some use cases, like 
passing along the result of a callback.


PHP would neither be the first nor the last to be using `void` in this way.


If the union types RFC[2] passes it
makes sense to allow `Foo | null` which allows something of type `Foo`
or `null`. To me it makes sense that if you then remove `Foo` you are
left with `null`, not `void`. My personal recommendation because of
this would be to use `null` for the return type and instead of `void`.


`null` would be a weird type, because it doesn't make sense as a 
parameter type, and as a return type, you don't really want to enforce 
returning null, you want to enforce not returning at all (see the 
example above). It feels like a poor man's substitute to me.


Thanks.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Good evening,

I'm reviving my Void Return Type RFC, this time for PHP 7.1:

https://wiki.php.net/rfc/void_return_type

Please read it and tell me your thoughts!

Thanks.

P.S. As it so (fatefully?) happens, I originally introduced this on 14th 
February, and it's now 14th October, so it's been exactly 8 months!


--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Stas,

Stanislav Malyshev wrote:


I still see no point in this, as every PHP function actually returns
something (at least null). So this type would not actually be right and
would not reflect what actually is happening.


It wouldn't be incorrect. Not all languages with `void` prevent a 
function's use as an expression (or 'rvalue' in C parlance). In some, it 
merely requires the function not to explicitly return a value.


And, heck, we use void in the PHP manual all the time.


Moreover, I don't see any scenario where some code depends on a function
not returning something explicitly (i.e. does not use return value) but
function actually returns something explicitly and the calling code
breaks. This appears to be impossible,


It most likely is, but it's not the only case that matters. What if you 
mistakenly return a value in a function that's not supposed to? This 
would catch you out.



and thus there's no reason to
declare a function "void" except purely for documentation purposes.
Adding keywords to the language just to document this does not look to
me like a good idea.


I feel that the basic facts about a function should be in the signature, 
and shouldn't have to be hidden in a comment, if only because it's more 
concicse and keeps information about parameters on the same line as the 
parameters themselves. Unlike comments, type hints can't lie, because 
they're actually enforced.


But, yes, it is mostly just useful for documentation. I can understand 
your objection there.


Thanks.
--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Stanislav Malyshev]

Hi!

> And, heck, we use void in the PHP manual all the time.

Yes, because PHP manual *is* the documentation :) Note that function
descriptions in the manual, while they are similar to PHP syntax, aren't
actually valid PHP, even after scalar typing introduction. Bizarrely
enough, they don't even match the return type syntax.

> It most likely is, but it's not the only case that matters. What if you
> mistakenly return a value in a function that's not supposed to? This
> would catch you out.

Why would I care about such a mistake? Why would I care so much that I
would need a special language-level construct to catch it? How many such
mistakes happen and are they critical enough to have the engine
bothering with going after them? I think such mistakes are extremely
rare and insignificant.

> I feel that the basic facts about a function should be in the signature,
> and shouldn't have to be hidden in a comment, if only because it's more

I guess we disagree here, because I do not think comments are "hidden",
and I do not think signature of the function should be the comment. In
fact, in Java for example (which seems to be the model language for the
strict typing aficionados) it is long standing best practice to actually
verify the javadoc comments as part of the build and fail the build if
they are missing or wrong. I am not advocating for doing (or not doing
:) this in PHP, but I do say documentation is not "hidden" and strict
typing is not the same as documentation. Moreover, in this case strict
typing implies something that is outright false - the function that is
declared void does return a value, namely null. Even worse, if you do
try to return exactly the same value, the RFC requires failure in this
case, which makes zero sense as precisely the same thing happens in both
cases.

> concicse and keeps information about parameters on the same line as the
> parameters themselves. Unlike comments, type hints can't lie, because
> they're actually enforced.

In fact, it is the opposite - as I said above, that particular type does
lie, and it has to, because what it tries to express actually does not
exist in PHP.
I might be reluctantly ok with tolerating purely documentation type, but
tolerating purely documentation type that is in fact untrue does not
look good to me.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Korvin Szanto]

On Wed, Oct 14, 2015 at 3:47 PM Levi Morrison  wrote:

> On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev 
> wrote:
> > Hi!
> >
> >> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
> >>
> >> https://wiki.php.net/rfc/void_return_type
> >>
> >> Please read it and tell me your thoughts!
> >
> > I still see no point in this, as every PHP function actually returns
> > something (at least null). So this type would not actually be right and
> > would not reflect what actually is happening.
>
> I agree that `void` doesn't make sense given that we document that
> `return;` will return null[1].  If the union types RFC[2] passes it
> makes sense to allow `Foo | null` which allows something of type `Foo`
> or `null`. To me it makes sense that if you then remove `Foo` you are
> left with `null`, not `void`. My personal recommendation because of
> this would be to use `null` for the return type and instead of `void`.
>

Isn't null supposed to mean the absense of a value and not take the place
of a value in PHP though? Didn't we just have a long conversation about
this in a thread about PHPSadness?

If I capture the result of a "void" method and check if my result variable
with isset(), I'll get false. This sounds like it's void of value to me.


> Also, I do not think this feature is pointless. For instance, it has
> value in interfaces. Declaring that a method does not return a value
> means implementors cannot accidentally return something. This is
> better than just documenting that it should not be done.
>

This is what I was thinking too, I'm not sure that there's much value
beyond that


>   [1]: http://php.net/manual/en/function.return.php
>   [2]: https://wiki.php.net/rfc/union_types
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Levi Morrison]

On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
>>
>> https://wiki.php.net/rfc/void_return_type
>>
>> Please read it and tell me your thoughts!
>
> I still see no point in this, as every PHP function actually returns
> something (at least null). So this type would not actually be right and
> would not reflect what actually is happening.

I agree that `void` doesn't make sense given that we document that
`return;` will return null[1].  If the union types RFC[2] passes it
makes sense to allow `Foo | null` which allows something of type `Foo`
or `null`. To me it makes sense that if you then remove `Foo` you are
left with `null`, not `void`. My personal recommendation because of
this would be to use `null` for the return type and instead of `void`.

Also, I do not think this feature is pointless. For instance, it has
value in interfaces. Declaring that a method does not return a value
means implementors cannot accidentally return something. This is
better than just documenting that it should not be done.

  [1]: http://php.net/manual/en/function.return.php
  [2]: https://wiki.php.net/rfc/union_types

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Larry Garfield]

On 10/14/2015 06:00 PM, Andrea Faulds wrote:
Both you and Stas have said this, but it's only true if we solely 
consider C-like languages. Other languages do different things. In the 
PHP manual, Hack, TypeScript, ActionScript, and most likely other 
languages (these are just off the top of my head), `void` functions do 
still have an implicit result.


All of these languages would have had the choice to do what you're 
suggesting and use `null`, or its equivalent (`undefined` for 
TypeScript and ActionScript). They didn't. Why? If I had to guess, 
there's at least three reasons. For one, void is the word languages 
usually use for this. For another, `void` and `null` they mean 
different things. `void` signifies a function isn't returning 
anything. `null` signifies a function that *returns null*, regardless 
of where that null came from. `function foo(): null { return 
some_probably_null_returning_function(); }` should surely be legal 
with a `null` type hint, yet it's nonsensical code. Finally, making a 
function truly "return nothing", i.e. disallowing its use as an 
expression/rvalue, breaks some use cases, like passing along the 
result of a callback.


PHP would neither be the first nor the last to be using `void` in this 
way.



If the union types RFC[2] passes it
makes sense to allow `Foo | null` which allows something of type `Foo`
or `null`. To me it makes sense that if you then remove `Foo` you are
left with `null`, not `void`. My personal recommendation because of
this would be to use `null` for the return type and instead of `void`.


`null` would be a weird type, because it doesn't make sense as a 
parameter type, and as a return type, you don't really want to enforce 
returning null, you want to enforce not returning at all (see the 
example above). It feels like a poor man's substitute to me.


Thanks.


The tricky part here is that saying a function does not return is not 
something PHP currently does:


https://3v4l.org/HtAuC

No return implicitly returns NULL, which you can assign to a variable 
if, for some strange reason, you were so inclined.  So this would be 
more than "just" a syntactic documentation feature.


Which I believe gives the following options:

1) Change the language behavior such that

function foo() : void { ...}
$a = foo();

Is a syntax error (because there really was nothing returned to assign), 
rather than resulting in $a having a value of NULL.


2) Use null as a "type" (which I agree feels weird just saying it), such 
that:


function foo() : null { ...}
$a = foo();

and

function foo() { ...}
$a = foo();

are identical.  The former would impact the contents of the function 
(eg, a non-empty return would be a parse error), but the external result 
is the same ($a == NULL).


3) Use the "void" keyword, but give it the same effect as option 2.

The RFC currently seems to propose option 3 (based on the "Use of void 
functions in expressions" section).  I don't have a strong feeling at 
this point about which option I'd prefer.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Larry Garfield]

On 10/14/2015 06:30 PM, Andrea Faulds wrote:

Which I believe gives the following options:


1) Change the language behavior such that

function foo() : void { ...}
$a = foo();

Is a syntax error (because there really was nothing returned to assign),
rather than resulting in $a having a value of NULL.


As the RFC notes, this breaks things, and is inconsistent with how PHP 
already does things.



2) Use null as a "type" (which I agree feels weird just saying it), such
that:

function foo() : null { ...}
$a = foo();

and

function foo() { ...}
$a = foo();

are identical.  The former would impact the contents of the function
(eg, a non-empty return would be a parse error), but the external result
is the same ($a == NULL).


This would be strange. The manual doesn't say `null`, and I can't 
think of any language which uses `null` as the return type in this 
situation, even when they have the same implicit-null-return behaviour 
that PHP has (see the email you're replying to).


Also, wouldn't you expect this to behave like existing type hints, and 
let you return a null value from any source? But that's not what you 
would actually want, right?


Thanks.


Well, that depends on the intent here.  In practice, is the intent to 
add a "no return at all" type of function (ie, $a = foo() is a syntax 
error now where it was not before), or to make it explicit that the only 
legal return is null (even if implicitly that means having a non-early 
return statement is pointless)?  Those are the two options.  That may or 
may not dictate the keyword that gets used.


It definitely sounds like you're favoring the second (as that's what the 
RFC says).  Which may or make not make "void" an odd keyword to choose 
when what's actually happening is NULL getting returned.  Is NULL a 
void?  (There's a deep philosophical question...)


As I said, I don't have a strong opinion on the subject yet.  I'm just 
trying to distil the discussion down to as small a question as possible. :-)


Cheers.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Andrea Faulds]

Hi Larry,

Larry Garfield wrote:

The tricky part here is that saying a function does not return is not
something PHP currently does:

https://3v4l.org/HtAuC

No return implicitly returns NULL, which you can assign to a variable
if, for some strange reason, you were so inclined.  So this would be
more than "just" a syntactic documentation feature.


Which has been pointed out.


Which I believe gives the following options:

1) Change the language behavior such that

function foo() : void { ...}
$a = foo();

Is a syntax error (because there really was nothing returned to assign),
rather than resulting in $a having a value of NULL.


As the RFC notes, this breaks things, and is inconsistent with how PHP 
already does things.



2) Use null as a "type" (which I agree feels weird just saying it), such
that:

function foo() : null { ...}
$a = foo();

and

function foo() { ...}
$a = foo();

are identical.  The former would impact the contents of the function
(eg, a non-empty return would be a parse error), but the external result
is the same ($a == NULL).


This would be strange. The manual doesn't say `null`, and I can't think 
of any language which uses `null` as the return type in this situation, 
even when they have the same implicit-null-return behaviour that PHP has 
(see the email you're replying to).


Also, wouldn't you expect this to behave like existing type hints, and 
let you return a null value from any source? But that's not what you 
would actually want, right?


Thanks.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] Void Return Type

[François Laupretre]

Hi,

 De : Andrea Faulds [mailto:a...@ajf.me]
  following codes  still works:
 
$b = a();
 
  so, if you want a void return type, and if you want it to be a useful
feature..
 
  above expr should be invalid with an error  a() return nothing
 
 I'm not sure about this. PHP has always made functions valid rvalues, for
 better or for worse. This RFC could make void functions truly void

What about renaming this hint to 'null', instead of 'void'. I know that it
supports no explicit return and 'return;' with no value but what it does is
more checking that return value is null, than checking return value is
'void', whose concept is not defined yet.

It would remove the ambiguity on the fact that the return value is used or
not. The only justification is that, in PHP, not returning an explicit
value, or using 'return;' returns null, that's history, period.

I think it would make the concept easier to understand and would reserve the
ambiguous 'void' keyword for the future, if it finds a utility one day.

Cheers

François



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hey François,

On 14 Feb 2015, at 04:57, François Laupretre franc...@php.net wrote:

 That's a nice addition and a beginning to distinguish void from null, as I 
 imagine the function still returns null.
 
 Now, what about making void a real zval type ? It would open a lot of 
 possibilities. Unlike null, conversions from void would raise an error. It 
 would also be rejected as argument input type but could be used as an output 
 type when arg is passed by ref, it could be the default type for return_value 
 (huge BC break here) and so on...

We could do this, but for the longest time we've made all functions have some 
return value, even ones which don't explicitly return one (they return NULL). I 
think it'd be better not to change this. I expect IDEs and such could earn you 
about it, though.

 There's a need for a real 'no value' type different from null, as null has 
 too many uses. If defined correctly, it can be a powerful addition.

If I was to go back to 1994, I'd add undefined to PHP like JS has. Today, 
though, I think that is unrealistic, as much as I wish it wasn't. A void type 
only really makes sense as a pseudo-type for return type checking purposes, IMO.


Thanks.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hi,

 On 14 Feb 2015, at 03:32, reeze re...@php.net wrote:
 
 Do we really have to throw an catchable fatal error?
 
 the other return types make sense, why so strict?

We throw E_RECOVERABLE_ERROR for all type errors, both for parameters and 
return types. It's not anything new.

--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type

[Alain Williams]

On Sat, Feb 14, 2015 at 12:26:08PM +, Andrea Faulds wrote:

 We could do this, but for the longest time we've made all functions have some 
 return value, even ones which don't explicitly return one (they return NULL). 
 I think it'd be better not to change this. I expect IDEs and such could earn 
 you about it, though.

All *existing* functions have a return value. That would not change.

If someone makes one of their functions void then where they use it could not be
where a value is needed. So: expect it in new code; but in 5 years time that
code will be mature.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hi,

 On 14 Feb 2015, at 05:03, Xinchen Hui larue...@php.net wrote:
 
 Hey:
 be honest, I think it's only part of the idea is implemented.
 
 which make it useless.
 
 in PHP, even if you don't return anything, NULL is returned implicitly.
 
 even if a function is declared return nothing(void).
 
 like:
 
   function a() : void {};
 
 following codes  still works:
 
   $b = a();
 
 so, if you want a void return type, and if you want it to be a useful 
 feature..
 
 above expr should be invalid with an error  a() return nothing

I'm not sure about this. PHP has always made functions valid rvalues, for 
better or for worse. This RFC could make void functions truly void, but that 
would be a massive change to support value-less function returns. It would also 
break existing code which assumes all functions return a value, which isn't 
good.

I think this RFC is enough: it would let you enforce that a function doesn't 
return anything and makes code more self-documenting. It doesn't affect 
anything trying to use the function's implicit return value of NULL, but IDEs 
and code linters would surely pick up on it for you. It's still useful even if 
it doesn't bind the caller.

Thanks.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type

[Andrea Faulds]

Hi,

 On 14 Feb 2015, at 05:54, Stanislav Malyshev smalys...@gmail.com wrote:
 
 Hi!
 
 I'm not sure what it is useful for, exactly. I mean, the more fatal
 errors the merrier, but I fail to see what exactly use except having yet
 more cases when your code may break it provides. I mean, if you defined
 a void function, that means you're not using it return value anywhere.
 Then who cares what return statement says?

What would be the point of *allowing* returning a value? It's clearly an error. 
We could let you return anything and then discard it, but now you won't spot 
the error in your code.

 Additionally, this RFC gets inheritance wrong - having return from
 function that previously did not return anything is not a violation of
 contract, since there's no practical contract that can rely on function
 not returning anything (in fact, there's no way in PHP to even check
 that AFAIK).

I am wondering about inheritance as well. I thought of void as having no 
subclass. But it's not really a return type for our purposes, it's more like a 
declaration that a function doesn't return anything.

So, I guess inheritance should allow removing or changing the typehint if it is 
void. I might need more opinions on this first, though.

 Summarily, this seems to me an exercise in strictness for the sake of
 strictness. There are languages that force people to abide by a lot of
 rules because their creators believe more rules is the same as better
 code, but PHP never was one of them and the fact there are so many
 people trying to make PHP that makes me sad.

It's not merely for the sake of it. It makes function signatures more 
descriptive, and lets you catch bugs in your code.

We already use void in the manual: why not in PHP?

--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type

[Stanislav Malyshev]

Hi!

 What would be the point of *allowing* returning a value? It's clearly

It's an error only because you declared it an error.

 an error. We could let you return anything and then discard it, but
 now you won't spot the error in your code.

Function return values which are going unused all the time. In PHP,
functions are very frequently called for side effects and not return
values. So returning value and discarding it is a common and perfectly
valid scenario. And it also has absolutely nothing to do with void
declaration - void declaration doesn't cause discarding the value and
you can discard the value with or without it.

 It's not merely for the sake of it. It makes function signatures more
 descriptive, and lets you catch bugs in your code.

Only bug it can catch is wrongly declaring the function to be void -
which is introduced by this RFC. For me, it is a clear case of
generating error for the sake of error.

 We already use void in the manual: why not in PHP?

Because the manual is the *documentation*, not code. It explains that
the function does not return anything useful. It's not the same as
creating an error when function returns something useful.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Void Return Type

[Nikita Popov]

On Sat, Feb 14, 2015 at 3:28 PM, Stanislav Malyshev smalys...@gmail.com
wrote:

 Hi!

  What would be the point of *allowing* returning a value? It's clearly

 It's an error only because you declared it an error.

  an error. We could let you return anything and then discard it, but
  now you won't spot the error in your code.

 Function return values which are going unused all the time. In PHP,
 functions are very frequently called for side effects and not return
 values. So returning value and discarding it is a common and perfectly
 valid scenario. And it also has absolutely nothing to do with void
 declaration - void declaration doesn't cause discarding the value and
 you can discard the value with or without it.

  It's not merely for the sake of it. It makes function signatures more
  descriptive, and lets you catch bugs in your code.

 Only bug it can catch is wrongly declaring the function to be void -
 which is introduced by this RFC. For me, it is a clear case of
 generating error for the sake of error.

  We already use void in the manual: why not in PHP?

 Because the manual is the *documentation*, not code. It explains that
 the function does not return anything useful. It's not the same as
 creating an error when function returns something useful.


One of the primary purposes of having typehints *is* documentation. This
applies both to our existing type annotations, to the newly introduced
return declarations - and to the void return type. The advantage of having
the type declaration be part of the language (rather than a docblock) is
brevity on one hand and verification of its correctness on the other hand.
It's easy to forget to update docblock type annotations, but you can't get
away with specifying an incorrect language-supported annotations - if you
use a wrong type annotation your code just won't work.

The void return type is actually the one case where we can at compile-time
fully verify that it is used correctly - which is great.

Allowing to return a value from a void function doesn't make sense. If you
want to return a value, don't declare it as void. If you declare it as
void, don't return a value. It's really as simple as that.

Nikita

Re: [PHP-DEV] [RFC] Void Return Type

[Pierre Joye]

On Feb 14, 2015 6:28 AM, Stanislav Malyshev smalys...@gmail.com wrote:

 Hi!

  What would be the point of *allowing* returning a value? It's clearly

 It's an error only because you declared it an error.

  an error. We could let you return anything and then discard it, but
  now you won't spot the error in your code.

 Function return values which are going unused all the time. In PHP,
 functions are very frequently called for side effects and not return
 values. So returning value and discarding it is a common and perfectly
 valid scenario. And it also has absolutely nothing to do with void
 declaration - void declaration doesn't cause discarding the value and
 you can discard the value with or without it.

I have no strong opinion on the void but reading this exact comment makes
me think that there is clearly an issue here.

How ignoring values is a perfectly valid scenario? Yes, there are cases
where some code does not need it but it is clearly not clean nor correct.

  It's not merely for the sake of it. It makes function signatures more
  descriptive, and lets you catch bugs in your code.

 Only bug it can catch is wrongly declaring the function to be void -
 which is introduced by this RFC. For me, it is a clear case of
 generating error for the sake of error.

No. It makes clear about what happens and what should be expected. I see it
as a complement to the return type rfc.

  We already use void in the manual: why not in PHP?

 Because the manual is the *documentation*, not code. It explains that
 the function does not return anything useful. It's not the same as
 creating an error when function returns something useful.

I did not check the implementation yet but I suppose it does not default to
void, f.e. for existing codes. So I do not see about which errors you are
talking about here.

However yes, future codes (lib, apps, etc) using void will create this
error and it will be pretty easy to make the caller happy, no?

A common thing I see lately is to look at legacy code to consider what
should or can be php tomorrow. I consider it as a strategic mistake. I am
not saying we should drastically change php or force users to rely on new
paradigms. But we must provide features to make php relevant for a wider
audience. And it is possible to do it without making it less easy to use.
We had the same discussion about OO when we developed 5.0, see where we are
now. Stronger than ever.

Cheers,
Pierre