Re: RFC - Array slice syntactic sugar

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

« previous php.internals (#85273) next »