>
> First, yeesh, where were y'all 2 weeks ago? :-P
>
I searched for the `as` vs `=>` discussion on the current thread (ref:
https://externals.io/message/129077) and it didn't exist until now. Then I
found the discussion happened on the Examples comparing Block Scoped RAII
and Context Managers (ref: https://externals.io/message/129251). I wasn't
following that discussion because I thought it was mostly about comparing
both implementations and taking knowledge from it. I didn't expect *that*
to make this RFC to change without it being discussed here.
> Second, I find it fascinating that there's so many different
> mutually-incompatible spins on what => means. As argued in the
> short-functions and auto-capture-closure RFCs from a few years ago, => in
> nearly all cases currently means "evaluates to."
>
> $arr = [
> 'a' => 'A",
> 'b' => 'B',
> ];
>
> $arr['a'] // This "evaluates to" A
>
> match ($foo) {
> 'a' => 'A',
> 'b' => 'B', // The 'b' case "evaluates to" B
> };
>
> fn($foo) => 'bar'; // This function "evaluates to" bar
>
> foreach ($arr as $k => $v) {}
>
> The last is a little bit inconsistent, but can still be read as "$k, and
> the thing that $k evaluates to."
>
I think the problem might be less about the true meaning of => and more
about the context that it applies to. You can see that in 3 cases of the
arrow it involves some sort of key/value pair (2 array scenarios and 1
match/case). In the case of arrow function, like I said before, arrow
functions are kind of a standard that stand up on their own. And even then,
the "evaluates to" is only partially because in arrow functions the
evaluation does not take immediate effect, it is parsed into a Closure that
needs to be invoked. For instance:
```
$array = [
'key' => throw new Exception('Stop'),
];
```
Here, the arrow evaluates to an exception that is immediately thrown.
```
match ($foo) {
'a' => throw new Exception('Stop because of A'),
'b' => throw new Exception('Stop because of B'),
};
```
Here, the evaluation is more loose and it only takes effect when there is a
match, but it does take effect.
```
fn () => throw new Exception('Stop');
```
Here, the evaluation never takes effect if the Closure is not invoked.
In these 3 cases, we can see each having its own evaluation rule:
immediate, immediate only for the match, and delayed. If I were to put into
words, I'd say:
array keys: evaluates to
match: evaluate to the matched key
arrow function: parse the syntax, does not evaluate to.
```
foreach ($arr as $k => $v) {}
```
Here I don't see it only as a bit inconsistent because it's not really
evaluating anything anymore. It is assigning a value. And this is where it
blows up for me. The first 3 cases we can argue semantics and point of
views, but they are minor nuances. Still, they're all cases where something
on the right is being evaluated for a reason on the left. On foreach, $v
stands on its own. It's not affected / impacted / dicated / evaluated
towards the left at all. It's not a bit inconsistent, it's completely
different. And the syntax for using () is largely similar to foreach, which
is why it should use `as` and not `=>`.
foreach ($iterator as $key => $value)
using ($contextManager as $context)
We can see that the only place where arrow ("evaluates to" / =>) is used
inside an instruction is in foreach and the syntax is split away from the
array itself because the keyword `as` is separating `$k => $v` from the
$iterator. I can totally see an argument for:
using (new ContextManager as $contextManager which evaluates to $context)
using (new ContextManager as $contextManager => $context)
Here, the return of `enter` would be [$this, $context] and the syntax falls
into place with a symmetry from foreach. I wouldn't strongly push for this
syntax because the following also works
using ($manager = new ContextManager as $context)
In any case, I don't have a vote and I really like the RFC in general. With
proper IDE support, I'm sure we will all get used to =>, but from where I
stand that's going to be really awkward for the PHP syntax.
--
Marco Deleu
