I like it. Only exception is:
```
fn&() => ...;
```
Which I would prefer to see reserved for the purpose that you've written as:
```
fn() use(&) => ...;
```
The & symbol of "return by ref", should be placed on the right of the
parentheses, near the return type:
```
fn(int &$x)&: int => $x;
fn(
On Fri, 15 Mar 2019 at 10:10, Nikita Popov wrote:
> It might be worth giving some consideration to the possibility of
> introducing this syntax already in this RFC. The main problem with punting
> this off for later is that it may be necessary to refactor closures between
> the short and the long
On Fri, Mar 15, 2019 at 10:31 AM Rowan Collins
wrote:
> On Fri, 15 Mar 2019 at 09:01, Alexandru Pătrănescu
> wrote:
>
> > My question would be: whatever syntax we are going to use that has arrow
> > syntax, let's say *$f = \($x) => $x * 2;* are we going to also support
> the
> > arrow block vers
On Thu, Mar 14, 2019 at 3:04 PM Mathieu Rochette
wrote:
>
> Hi,
>
> it's nice to see this going on again :)
>
> while reading the rfc I was wondering, why do we need the "static"
> keyword, couldn't static function be detected automatically ?
>
I've added a note regarding this in
https://wiki.ph
On Fri, 15 Mar 2019 at 09:01, Alexandru Pătrănescu
wrote:
> My question would be: whatever syntax we are going to use that has arrow
> syntax, let's say *$f = \($x) => $x * 2;* are we going to also support the
> arrow block version?:
> *$f = \($x) => {*
> *// more operations that will have be
Hi,
To start with, I personally understand why a prefix character is needed
before parenthesis to make the parser simpler. I would like another simpler
option but will have to investigate more on this.
My question would be: whatever syntax we are going to use that has arrow
syntax, let's say *$f
On Thu, 14 Mar 2019 at 18:20, Josh Di Fabio wrote:
> On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins
> wrote:
> >
> > Is it really that important to save two key strokes per closure?
> >
>
> I'd say that the (probably overwhelming) majority of arrow functions
> have a single parameter and, in thos
On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins wrote:
>
> Is it really that important to save two key strokes per closure?
>
I'd say that the (probably overwhelming) majority of arrow functions
have a single parameter and, in those cases, the JS syntax saves four
characters, ignoring whitespace. A
On Thu, 14 Mar 2019 at 15:10, Benjamin Morel
wrote:
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
>> lookahead.
>
>
> You're right, I was only thinking about resolving the ambiguity with array
> keys. It's too bad if the parser implementation considerations take
> pr
Em qui, 14 de mar de 2019 às 03:17, Rowan Collins
escreveu:
> I don't think this helps, because you can put brackets around any
> expression, for precedence, and any expression can appear on the left of an
> array literal:
>
> $foo = [ ($bar + 1) * 2 => $baz ];
>
> So the following, while redunda
>
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
> lookahead.
You're right, I was only thinking about resolving the ambiguity with array
keys. It's too bad if the parser implementation considerations take
precedence over the purity of the language, but I can understan
On Thu, 14 Mar 2019 at 14:12, Benjamin Morel
wrote:
> This makes me thinking, has this syntax been considered?
>
> ($x) => { $x * $y }
>
> Nested:
>
> ($x) => { ($y) => { $x * $y } }
>
Wouldn't this have all the same parser problems as the RFC discusses?
The problem, as I understand it, is not
This makes me thinking, has this syntax been considered?
($x) => { $x * $y }
Nested:
($x) => { ($y) => { $x * $y } }
AFAICS, we don't need the brackets around the whole expression, as this
should be parsable without any ambiguity; and the syntax would be closer to
that of JavaScript.
On Thu,
Hi,
it's nice to see this going on again :)
while reading the rfc I was wondering, why do we need the "static" keyword,
couldn't static function be detected automatically ?
I guess this apply to the existing closure syntax as well so to get more on
this topic I'll share my preferences on th
On 13 March 2019 15:56:40 GMT+00:00, Nikita Popov wrote:
>Motivated by the recent list comprehensions RFC, I think it's time we
>took
>another look at short closures:
>
>https://wiki.php.net/rfc/arrow_functions_v2
Hi Nikita,
Thanks for reviving this. I think the RFC does a great job of
justifyin
On 14 March 2019 04:01:54 GMT+00:00, David Rodrigues
wrote:
>1. Your example with "($x) => $x" consider the use of "$x => $x", but
>not
>specifically "($x) => $x". I mean: maybe it can accept "($x) => $x" but
>not
>"$x => $x" because of the array conflict (as mentioned), and with that
>we
>avoid
I have two doubts about the RFC:
1. Your example with "($x) => $x" consider the use of "$x => $x", but not
specifically "($x) => $x". I mean: maybe it can accept "($x) => $x" but not
"$x => $x" because of the array conflict (as mentioned), and with that we
avoid to create a new keyword "fn". So pa
On Wed, Mar 13, 2019, at 11:57 AM, Nikita Popov wrote:
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & B
Den 2019-03-13 kl. 16:56, skrev Nikita Popov:
Hi internals,
Motivated by the recent list comprehensions RFC, I think it's time we took
another look at short closures:
https://wiki.php.net/rfc/arrow_functions_v2
This is based on a previous (withdrawn) proposal by Levi & Bob. It uses the
syntax
> On Mar 13, 2019, at 15:56, Rowan Collins wrote:
>
> I suggest you both read the RFC; about half the page is dedicated to
> summarising the syntaxes which have been considered, and the pros and cons of
> each.
>
> The summary of that syntax begins:
>
> > This is both the most popular and the
On 13/03/2019 20:37, Chase Peeler wrote:
Anyone considered? ($x) => $x * $multiplier
I use this format a lot in javascript, so I like not having any indicator.
I can't remember which language it was, but they didn't even require the
parentheses if there was only a single input:
$x => $x * $mult
On Wed, Mar 13, 2019 at 4:26 PM Travis van der Font
wrote:
> Arrow functions are ternary operators to functions.
> While they are nice and shorten, they can be hard to read at times;
> considerably to people who aren't used to them which is surprisedly a
> majority of PHP programmers.
>
> Having
Arrow functions are ternary operators to functions.
While they are nice and shorten, they can be hard to read at times;
considerably to people who aren't used to them which is surprisedly a
majority of PHP programmers.
Having them optional sure, but not necessary.
Feel free to decide between fn()
> On Mar 13, 2019, at 10:56, Nikita Popov wrote:
>
> Hi internals,
>
> Motivated by the recent list comprehensions RFC, I think it's time we took
> another look at short closures:
>
> https://wiki.php.net/rfc/arrow_functions_v2
>
> This is based on a previous (withdrawn) proposal by Levi & Bob
Hi internals,
Motivated by the recent list comprehensions RFC, I think it's time we took
another look at short closures:
https://wiki.php.net/rfc/arrow_functions_v2
This is based on a previous (withdrawn) proposal by Levi & Bob. It uses the
syntax
fn($x) => $x * $multiplier
and implicit by
Den 2015-10-03 kl. 01:17, skrev Levi Morrison:
I messaged the list about this feature before I had the RFC written up
for it. The RFC[1] is slightly different from what I proposed in the
previous thread, so please read the RFC to make sure you understand
what is being proposed before replying her
Pavel Kouřil wrote on 03.10.2015 10:06:
> On Sat, Oct 3, 2015 at 1:17 AM, Levi Morrison wrote:
>> I messaged the list about this feature before I had the RFC written up
>> for it. The RFC[1] is slightly different from what I proposed in the
>> previous thread, so please read the RFC to make sure
On Sat, Oct 3, 2015 at 1:17 AM, Levi Morrison wrote:
> I messaged the list about this feature before I had the RFC written up
> for it. The RFC[1] is slightly different from what I proposed in the
> previous thread, so please read the RFC to make sure you understand
> what is being proposed before
I messaged the list about this feature before I had the RFC written up
for it. The RFC[1] is slightly different from what I proposed in the
previous thread, so please read the RFC to make sure you understand
what is being proposed before replying here.
Here's a small example:
$y = 10;
$re
29 matches
Mail list logo
