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