Re: RFC - Array slice syntactic sugar
| From: | Alex Bowers | Date: | Fri, 20 Mar 2015 11:38:35 +0000 |
| Subject: | Re: RFC - Array slice syntactic sugar | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-85273@lists.php.net to get a copy of this message | ||
>
> The @ symbol in my examples is not a special marker that is meaningful on
> its own; the parser wouldn't even see it as a separate token. The syntax
> for key access is $array[$key], the syntax for positional access would be
> $array[@$position]; chosen to look similar, but one is not a special case
> of the other.
Ah, I understand you now. Yes I agree that this would be useful then. It
allows us the future possibility of a separate RFC looking into slicing on
keys as mentioned at the bottom of your post.
The syntax needn't be just an extra character, we could invent something
> else, like $array[[$position]], or $array@($position), though I can't
> think of anything I like.
I think for simplicity, we should keep it as $array[], and have a symbol
within it that shows that it is an internal index rather than the key. An
Asterisk (*) is my preference at the moment, though caret also looks
promising.
Here are some examples of how various characters could look
$array[*1:3], $array[*:], $array[*:1], $array[*1:]
$array[@1:3], $array[@:], $array[@:1], $array[@1:]
$array[^1:3], $array[^:], $array[^:1], $array[^1:]
$array[&1:3], $array[&:], $array[&:1], $array[&1:]
The symbol isn't something that can be missing, it's just part of the
> syntax, so this is like saying "what should we do if the closing ] is
> missing?" The answer is, nothing, it's undefined syntax, so it's a parse
> error.
So a parse error currently, and a future RFC can define the terms of using
this normally?
If we go down the route of adding a symbol for by index rather than by key,
then this RFC should also include the normal getting array by key style,
without the colon range operator.
For example:
$array[*1] to get the item that is the second in the list, rather than at
key 1.