[RFC] Return Type Declarations

Nice proposal.

FWIW on the use issue I much prefer the first alternative:

function ($foo): Bar use ($quux) {}
function ($foo) use ($quux): Bar {}

Hello,

2014-04-24 17:59 GMT+02:00 Levi Morrison levim@php.net:

My dear Internals friends,

I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehinting

Notable items:

• Differences from past RFCs are summarized in the RFC:
  https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs
• The patch includes basic opcache and reflection support. It also has
  phpt tests.
• Informal performance tests indicate that the patch did not fubar
  performance; if desired a more detailed test can be conducted before
  voting.
• This RFC does not add, modify, or remove keywords at all; this
  notably
  excludes type-hints for scalars. Supporting scalar type declarations is
  outside the scope of this RFC; if you are interested in supporting scalar
  type declarations please discuss it elsewhere.

As a friendly reminder, everyone on this list is interested in
developing a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!

Some thanks, regardless if the RFC is accepted:

• For providing a patch: Joe Watkins.
• For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
  Anthony Ferrara
• For previous RFCs on this topic: Felipe Pena and Will Fitch. I
  gleaned
  valuable knowledge from your proposals and the discussion around them.

This is a nice and well thought proposal.

I would like to suggest the addition of the "self" and "static" pseudo
types. Most IDEs support this through @return syntax:

class Foo {
/** @return static */
public function SetBar( $bar ) {
// ...
return $this;
}
}

With the new syntax, the above could be transformed into this:

class Foo {
public function SetBar( $bar ) : static {
// ...
return $this;
}
}

Lazare INEPOLOGLOU
Ingénieur Logiciel

--
Pete Boere
Web Developer

On Fri, Apr 25, 2014 at 3:09 AM, Lazare Inepologlou linepogl@gmail.comwrote:

Hello,

2014-04-24 17:59 GMT+02:00 Levi Morrison levim@php.net:

My dear Internals friends,

I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehinting

Notable items:

• Differences from past RFCs are summarized in the RFC:
  https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs
• The patch includes basic opcache and reflection support. It also has
  phpt tests.
• Informal performance tests indicate that the patch did not fubar
  performance; if desired a more detailed test can be conducted before
  voting.
• This RFC does not add, modify, or remove keywords at all; this notably
  excludes type-hints for scalars. Supporting scalar type declarations is
  outside the scope of this RFC; if you are interested in supporting scalar
  type declarations please discuss it elsewhere.

As a friendly reminder, everyone on this list is interested in developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!

Some thanks, regardless if the RFC is accepted:

• For providing a patch: Joe Watkins.
• For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
  Anthony Ferrara
• For previous RFCs on this topic: Felipe Pena and Will Fitch. I gleaned
  valuable knowledge from your proposals and the discussion around them.

This is a nice and well thought proposal.

I would like to suggest the addition of the "self" and "static" pseudo
types. Most IDEs support this through @return syntax:

class Foo {
/** @return static */
public function SetBar( $bar ) {
// ...
return $this;
}
}

With the new syntax, the above could be transformed into this:

class Foo {
public function SetBar( $bar ) : static {
// ...
return $this;
}
}

As the patch currently stands you can use the type-hint 'self'.

(Apparently only replied to Sebastian while on mobile :)

I know this RFC does not address multiple return types on purpose.

But supposing it's implemented in its current form, what would be a
possible syntax for multiple/mixed return types?

Namely for the usual suspects of string|null, array|null, Class|bool,
or ClassA|ClassB|bool, etc...

Something along those lines.

Cheers

My dear Internals friends,

I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehinting

Notable items:

• Differences from past RFCs are summarized in the RFC:
  https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs
• The patch includes basic opcache and reflection support. It also has
  phpt tests.
• Informal performance tests indicate that the patch did not fubar
  performance; if desired a more detailed test can be conducted before
  voting.
• This RFC does not add, modify, or remove keywords at all; this
  notably
  excludes type-hints for scalars. Supporting scalar type declarations is
  outside the scope of this RFC; if you are interested in supporting scalar
  type declarations please discuss it elsewhere.

As a friendly reminder, everyone on this list is interested in developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!

Some thanks, regardless if the RFC is accepted:

• For providing a patch: Joe Watkins.
• For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
  Anthony Ferrara
• For previous RFCs on this topic: Felipe Pena and Will Fitch. I
  gleaned
  valuable knowledge from your proposals and the discussion around them.

Simple, targeted, focused, I like. I very much like the NULL handling, as
it means as a caller I have to do less work.

One bit strikes me as odd. In the invalid examples, you have this example:

function foo(): array {
yield [];
}

which generates this error:

Fatal error: Generators may only yield objects, array is not a valid type in
%s on line %d

Except Generators can totally yield arrays currently:

function foo() {
yield [];
}
foreach (foo() as $x) print_r($x) . PHP_EOL;

The above works perfectly on 5.5.10, where I just tested it.

So what's with that error condition? Clearly from the RFC we can specify
array as a return type, so I don't know why it calls out generators as
specially limited.

As I write that I suspect it's because generators actually "return" an
interator object, and so the return type of the generator is being
interpreted relative to the construction, not iteration, of the generator.
That seems like a likely source of confusion, as I would, as a developer,
expect to be specifying the type that gets returned from iteration, not from
construction, so that my foreach loop (or similar) can rely on the type
being returned.

I think this part warrants further consideration. The rest of the RFC I
fully look forward to using.

As far as the order of keywords in a closure, what order does Hack use? The
rest of the syntax seems based on it, so it seems sensible to follow suit.
(I couldn't find that information from 60 seconds on hacklang.org, but it
may be there.)

--Larry Garfield

On Mon, Apr 28, 2014 at 12:16 PM, Larry Garfield larry@garfieldtech.comwrote:

My dear Internals friends,

I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehinting

Notable items:

• Differences from past RFCs are summarized in the RFC:
  https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs
• The patch includes basic opcache and reflection support. It also has
  phpt tests.
• Informal performance tests indicate that the patch did not fubar
  performance; if desired a more detailed test can be conducted before
  voting.
• This RFC does not add, modify, or remove keywords at all; this
  notably
  excludes type-hints for scalars. Supporting scalar type declarations is
  outside the scope of this RFC; if you are interested in supporting scalar
  type declarations please discuss it elsewhere.

As a friendly reminder, everyone on this list is interested in developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!

Some thanks, regardless if the RFC is accepted:

• For providing a patch: Joe Watkins.
• For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
  Anthony Ferrara
• For previous RFCs on this topic: Felipe Pena and Will Fitch. I
  gleaned
  valuable knowledge from your proposals and the discussion around them.

Simple, targeted, focused, I like. I very much like the NULL handling, as
it means as a caller I have to do less work.

Thank you.

One bit strikes me as odd. In the invalid examples, you have this example:

function foo(): array {
yield [];
}

which generates this error:

Fatal error: Generators may only yield objects, array is not a valid type
in %s on line %d

Except Generators can totally yield arrays currently:

function foo() {
yield [];
}
foreach (foo() as $x) print_r($x) . PHP_EOL;

The above works perfectly on 5.5.10, where I just tested it.

So what's with that error condition? Clearly from the RFC we can specify
array as a return type, so I don't know why it calls out generators as
specially limited.

As I write that I suspect it's because generators actually "return" an
interator object, and so the return type of the generator is being
interpreted relative to the construction, not iteration, of the generator.
That seems like a likely source of confusion, as I would, as a developer,
expect to be specifying the type that gets returned from iteration, not
from construction, so that my foreach loop (or similar) can rely on the
type being returned.

The type hint is purposefully not the type of the value returned; a
generator always returns a generator. I will clarify this in the RFC and
maybe adjust the wording in the error message as well to better indicate
this.

I think this part warrants further consideration. The rest of the RFC I
fully look forward to using.

Special casing a generator's return type would be an inconsistency in the
design. If you var_dump() something that returns generator it tells you it
is a generator; this should match the type of the return value and anything
else is unexpected. As an example, using a generator to fulfill an Iterator
return type should succeed; special casing the Generator would complicate
the code to achieve this. Special casing the generator would also infringe
on other future ideas, such as adding generics to the language. All in all,
special casing generators doesn't make sense.

As far as the order of keywords in a closure, what order does Hack use?

The rest of the syntax seems based on it, so it seems sensible to follow
suit. (I couldn't find that information from 60 seconds on hacklang.org,
but it may be there.)

At least in the 2.4 branch of HHVM (which I have installed) they put it
before the use statement. Now that I have thought about this more, this is
a poor decision:

• use statements are basically parameters at construction time instead of
  runtime
• putting the return type before the use statement looks really ugly

I will attempt to contact the HHVM team (perhaps SaraG) to see if there was
a technical reason for it.