# [RFC] Return Type Declarations

- Thread: https://externals.io/message/73774
- Original archive: https://news-web.php.net/php.internals/73774
- Started by Levi Morrison on 2014-04-24T15:59:19+00:00
- Messages: 28
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/73774.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #73774 — Levi Morrison — 2014-04-24T15:59:19+00:00

URL: https://externals.io/message/73774#73774

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.

---

## #73777 — Tyler Sommer — 2014-04-24T17:07:15+00:00

URL: https://externals.io/message/73774#73777 · In reply to: #73774

> My dear Internals friends,
> 
> I have spent the last month drafting an RFC that allows return types:
> https://wiki.php.net/rfc/returntypehinting
> 

As a PHP user, this is great. Finally we can stop using silly docblock comments to denote return types!


+1 from me!

---

## #73778 — Alain Williams — 2014-04-24T17:22:51+00:00

URL: https://externals.io/message/73774#73778 · In reply to: #73774

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

Well, I think that that should be added here also your future work of 'void'.
So, add: int, float, numeric (int or float), string, bool, void.

Sorry.

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

---

## #73779 — Philip Sturgeon — 2014-04-24T17:59:04+00:00

URL: https://externals.io/message/73774#73779 · In reply to: #73774

> 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 will come in very handy over at the PHP-FIG, as we can specify
return types for interface methods instead of just type hinting parameters.

All for it. This has been done in a way that is fully BC, resolves any
of the previous complaints, offers useful functionality, does not bite
off more than it can chew, ignores the whole "nullable AND specific
type" black hole and gets the job done.

Best of luck with this one Levi.

---

## #73794 — Lazare Inepologlou — 2014-04-25T09:09:08+00:00

URL: https://externals.io/message/73774#73794 · In reply to: #73774

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

---

## #73795 — Pete Boere — 2014-04-25T10:08:31+00:00

URL: https://externals.io/message/73774#73795 · In reply to: #73794

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>:
>
> > […]
> notably
> > […]
> developing a
> > […]
> gleaned
> > […]
>
>
> 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

---

## #73796 — Christian Stoller — 2014-04-25T12:31:04+00:00

URL: https://externals.io/message/73774#73796 · In reply to: #73795

> From: Pete Boere [mailto:pete@the-echoplex.net] 
>
> Nice proposal.
>
> FWIW on the `use` issue I much prefer the first alternative:
>
> function ($foo): Bar use ($quux) {}
> function ($foo) use ($quux): Bar {}
>

I like the idea and the FRC, too!

But referring to the `use` issue: Just from reading the first alternative 
sounds like "Bar uses xy", which sounds strange to me. I'd prefer the 
second alternative.

---

## #73798 — Levi Morrison — 2014-04-25T14:52:10+00:00

URL: https://externals.io/message/73774#73798 · In reply to: #73794

On Fri, Apr 25, 2014 at 3:09 AM, Lazare Inepologlou <linepogl@gmail.com>wrote:

> Hello,
>
> 2014-04-24 17:59 GMT+02:00 Levi Morrison <levim@php.net>:
>
> My dear Internals friends,
> > […]
>
>
> 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'.

---

## #73799 — Will Fitch — 2014-04-25T14:59:55+00:00

URL: https://externals.io/message/73774#73799 · In reply to: #73798

> On Fri, Apr 25, 2014 at 3:09 AM, Lazare Inepologlou
> <linepogl@gmail.com>wrote:
> 
> > […]
> 
> As the patch currently stands you can use the type-hint 'self'.

How will this patch work with LSB?

---

## #73802 — Levi Morrison — 2014-04-25T21:10:30+00:00

URL: https://externals.io/message/73774#73802 · In reply to: #73799

> 
> > […]
> has
> > […]
> notably
> > […]
> is
> > […]
> scalar
> > […]
> developing
> > […]
> and
> > […]
> gleaned
> > […]
>
> How will this patch work with LSB?
>

Late static binding is not a feature I am very familiar with. After some
investigation it appears that we curently don't support late static binding
on parameters; this means that I will not support late static binding on
returns either. I want to keep the impact as small as possible.

---

## #73826 — Julien Pauli — 2014-04-28T09:23:51+00:00

URL: https://externals.io/message/73774#73826 · In reply to: #73802

> 
>
> > […]
>
> Late static binding is not a feature I am very familiar with. After some
> investigation it appears that we curently don't support late static binding
> on parameters; this means that I will not support late static binding on
> returns either. I want to keep the impact as small as possible.

Yep, this RFC is light and that's why it's nice :-)
I'm all +1 with it.

Keep the impact low as well as adding a nice, more-and-more-expected
feature, which keeps BC.
What should we ask for next ? :-)

You have my support.

Julien

---

## #73827 — Sebastian Bergmann — 2014-04-28T09:33:32+00:00

URL: https://externals.io/message/73774#73827 · In reply to: #73826

Am 28.04.2014 11:23, schrieb Julien Pauli:
> You have my support.

 Mine as well. I am for using the same syntax that Hack already has.

---

## #73831 — Larry Garfield — 2014-04-28T18:16:13+00:00

URL: https://externals.io/message/73774#73831 · In reply to: #73774

> 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

---

## #73832 — Daniel Macedo — 2014-04-28T18:18:28+00:00

URL: https://externals.io/message/73774#73832 · In reply to: #73831

(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


> 
> > […]
>
>
> 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

---

## #73834 — Levi Morrison — 2014-04-28T20:30:35+00:00

URL: https://externals.io/message/73774#73834 · In reply to: #73831

On Mon, Apr 28, 2014 at 12:16 PM, Larry Garfield <larry@garfieldtech.com>wrote:

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

---

## #73836 — Larry Garfield — 2014-04-28T21:43:58+00:00

URL: https://externals.io/message/73774#73836 · In reply to: #73834

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

So I suppose technically we should say that a generator must always 
return a Traversable?

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

That makes sense from an engine point of view, certainly.  From a user 
POV, I can still see it being the source of much confusion.  I confess 
I've barely used generators so far (PHP 5.5 still having very small 
market penetration), but it feels natural to mentally align return type 
/ return keyword and return type / yield keyword.  It also means I have 
no way of declaring that a generator will always return items of type X, 
which seems like a valid thing to do.

> As far as the order of keywords in a closure, what order does Hack use?
> > […]
>
>
> 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.

I would agree, and look forward to seeing their reasoning.

--Larry Garfield

---

## #73837 — Levi Morrison — 2014-04-29T01:19:57+00:00

URL: https://externals.io/message/73774#73837 · In reply to: #73836

On Mon, Apr 28, 2014 at 3:43 PM, Larry Garfield <larry@garfieldtech.com>wrote:

> 
>
>  As I write that I suspect it's because generators actually "return" an
> > […]
>
> So I suppose technically we should say that a generator must always return
> a Traversable?


Not quite: a generator always returns a Generator (this is an actual
object); so it can fulfill Generator, Iterator and Traversable.


>
>  I think this part warrants further consideration.  The rest of the RFC I
> > […]
>
> That makes sense from an engine point of view, certainly.  From a user
> POV, I can still see it being the source of much confusion.  I confess I've
> barely used generators so far (PHP 5.5 still having very small market
> penetration), but it feels natural to mentally align return type / return
> keyword and return type / yield keyword.  It also means I have no way of
> declaring that a generator will always return items of type X, which seems
> like a valid thing to do.


Agreed; however I would rather have all kinds of Iterators and collection
like object be able to type their values too. This would obviously fall
outside of this RFC so I have specifically left this possibility open
without directing its future too much.

---

## #73838 — Levi Morrison — 2014-04-29T01:30:01+00:00

URL: https://externals.io/message/73774#73838 · In reply to: #73836

>
> As far as the order of keywords in a closure, what order does Hack use?
> > […]
>
> I would agree, and look forward to seeing their reasoning.


HHVM puts the return type before the use case because:

  - A user is already familiar with function(): Foo
  - A use statement is not really part of the function signature (during
inheritance and such)

Additionally, it is common to write closures using their shorthand
notation: ==> (see http://docs.hhvm.com/manual/en/hack.lambda.php)

I would counter:
  - Use statements are special parameters (similar to constructor
arguments) and that putting it after the use statement makes more sense
  - Putting it after use statements is less ugly.
  - Putting it before the use statement is a bit confusing; consider this
Hack declaration:
        $i = 0;
        $inc = function(): Iterator<int> use(&$i) {//...
    It looks like the Iterator<int> is somehow using $i.

What does this list think?

---

## #73839 — Levi Morrison — 2014-04-29T01:34:11+00:00

URL: https://externals.io/message/73774#73839 · In reply to: #73837

>
> So I suppose technically we should say that a generator must always return
> > […]
>
>
> Not quite: a generator always returns a Generator (this is an actual
> object); so it can fulfill Generator, Iterator and Traversable.
>

A recent patch update actually says this in very clear terms; the RFC
simply fell a tad bit behind to reflect the improvement. It has now been
updated.

---

## #73845 — Larry Garfield — 2014-04-29T14:52:16+00:00

URL: https://externals.io/message/73774#73845 · In reply to: #73837

> > […]
>
>
> Agreed; however I would rather have all kinds of Iterators and collection
> like object be able to type their values too. This would obviously fall
> outside of this RFC so I have specifically left this possibility open
> without directing its future too much.

In other words, "let's punt on that until we figure out generics".  With 
the new error message in the RFC I can work with that.  Thanks.

--Larry Garfield

---

## #73846 — Larry Garfield — 2014-04-29T15:10:22+00:00

URL: https://externals.io/message/73774#73846 · In reply to: #73838

> > […]
>
>
> HHVM puts the return type before the use case because:
>
>    - A user is already familiar with function(): Foo
>    - A use statement is not really part of the function signature (during
> inheritance and such)
>
> Additionally, it is common to write closures using their shorthand
> notation: ==> (see http://docs.hhvm.com/manual/en/hack.lambda.php)
>
> I would counter:
>    - Use statements are special parameters (similar to constructor
> arguments) and that putting it after the use statement makes more sense
>    - Putting it after use statements is less ugly.
>    - Putting it before the use statement is a bit confusing; consider this
> Hack declaration:
>          $i = 0;
>          $inc = function(): Iterator<int> use(&$i) {//...
>      It looks like the Iterator<int> is somehow using $i.
>
> What does this list think?

Honestly I don't much care for the compact lambda syntax in Hack as I 
like that PHP is explicit on variable capture.  (Javascript isn't, and 
it's a common source of errors; see the "never do this" comment on the 
link above.)

<bikeshed>

I subjectively like the return at the very end, too.  The return is the 
"last" thing that matters, so it comes at the end.  Too, it clusters all 
of the inputs together (parameters and closures) followed by the output 
(return).

</bikeshed>

--Larry Garfield

---

## #74021 — Lin Yo-An — 2014-05-07T17:02:52+00:00

URL: https://externals.io/message/73774#74021 · In reply to: #73846

Hi,

Why using an additional ":" symbol for the return type? what about
considering this:

  function foo() string {  }

and for closure:

  $bar = 1;
  $foo = function() use ($bar) string {

  };

I think removing ":" symbol is cleaner.



On Tue, Apr 29, 2014 at 11:10 PM, Larry Garfield <larry@garfieldtech.com>wrote:

> 
>
>  I will attempt to contact the HHVM team (perhaps SaraG) to see if there
> > […]
>
> Honestly I don't much care for the compact lambda syntax in Hack as I like
> that PHP is explicit on variable capture.  (Javascript isn't, and it's a
> common source of errors; see the "never do this" comment on the link above.)
>
> <bikeshed>
>
> I subjectively like the return at the very end, too.  The return is the
> "last" thing that matters, so it comes at the end.  Too, it clusters all of
> the inputs together (parameters and closures) followed by the output
> (return).
>
> </bikeshed>
>
>
> --Larry Garfield
>
> --
> 
> 
>
>


-- 
Best Regards,

Yo-An Lin

---

## #74023 — Andrea Faulds — 2014-05-07T17:34:50+00:00

URL: https://externals.io/message/73774#74023 · In reply to: #74021

> Why using an additional ":" symbol for the return type? what about
> considering this:
> 
>  function foo() string {  }
> 
> and for closure:
> 
>  $bar = 1;
>  $foo = function() use ($bar) string {
> 
>  };
> 
> I think removing ":" symbol is cleaner.

Presumably it’s because TypeScript, ActionScript and Hack already use the `function foo() : type` form, so it’s a familiar syntax. However, Go uses the `func foobar() type` form, so there’s also precedent for that one. Considering the audience of PHP, TypeScript, ActionScript and Hack are probably more familiar than Go.

Maybe there’s a technical reason for it, though.
--
Andrea Faulds
http://ajf.me/

---

## #74039 — Levi Morrison — 2014-05-07T22:30:00+00:00

URL: https://externals.io/message/73774#74039 · In reply to: #74021

> Hi,
>
> Why using an additional ":" symbol for the return type? what about
> considering this:
>
>   function foo() string {  }
>
> and for closure:
>
>   $bar = 1;
>   $foo = function() use ($bar) string {
>
>   };
>
> I think removing ":" symbol is cleaner.


Your point is valid, certainly. We could omit it. Here are two minor things
to think about:

 1. Syntax is a visual indicator.
 2. Compatibility and familiarity to similar languages.

Syntax can be used to visually indicate things to the programmer. For
instance, the `()` in a conditional statement is not strictly necessary
from a language design perceptive and Go chose to omit them. Valid Go:

if $var === $null {

}

In our case the colon indicates that you are declaring a return type and
you can read it aloud as "returns". While not strictly necessary it does
give a visual indicator of what is going on.

function date_diff(DateTime $a, DateTime $b) : DateInterval;

The above function can be read aloud as:

"Function date_diff takes DateTime a and DateTime b and returns
DateInterval"

The colon indicates 'returns'. You can infer this from the context, sure;
again I did say this was a minor thing.

In the case of the colon I value being compatible with Hack more than the
small gain of omitting the colon.

---

## #74040 — Levi Morrison — 2014-05-07T22:31:34+00:00

URL: https://externals.io/message/73774#74040 · In reply to: #74039

>
> Valid Go:
>
> if $var === $null {
>
> }
>

(I wasn't perfectly clear; if PHP omitted the parenthesis like Go then it
would look like it does above)

---

Next page: https://externals.io/message/73774.md?page=2