Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85273
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7486C296-7535-4633-AFE2-02E7BBC67BC5@gmail.com>
References: <CAAn=CzWySWQU1D93WA7L2eHvd31zogekEHmDUOsN7P6kBK4VrA@mail.gmail.com>
	<550B5A81.1090706@gmail.com>
	<CAAn=CzUZPo=Yy79pRbot58nSR_tFqKYpd53kaAMbfxyUvz9Lwg@mail.gmail.com>
	<550B7189.4040608@gmail.com>
	<CAAn=CzUQc-av2dVBKwQg5xsCDiUXszfP1fWKVpBRMFNA3SjYEA@mail.gmail.com>
	<7486C296-7535-4633-AFE2-02E7BBC67BC5@gmail.com>
Date: Fri, 20 Mar 2015 11:38:35 +0000
Message-ID: <CAAn=CzXR=cU8Pq4wzNQXKLhqDt9WOF3CJfk2B=3z8DBtQhVvCg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11c3aa74b966240511b6c1b5
Subject: Re: [PHP-DEV] RFC - Array slice syntactic sugar
From: bowersbros@gmail.com (Alex Bowers)

--001a11c3aa74b966240511b6c1b5
Content-Type: text/plain; charset=UTF-8

>
> 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.

--001a11c3aa74b966240511b6c1b5--