# RFC - Array slice syntactic sugar

- Thread: https://externals.io/message/85238
- Original archive: https://news-web.php.net/php.internals/85238
- Started by Alex Bowers on 2015-03-19T20:49:15+00:00
- Messages: 69
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/85238.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #85238 — Alex Bowers — 2015-03-19T20:49:15+00:00

URL: https://externals.io/message/85238#85238

This email is just to gauge the response for some syntactic sugar to be
added to PHP in regard to slicing an array.

My proposal is something similar to Pythons slice, in PHP this would look
like:

$slided = $array[1:4]

This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),
ignoring the actual key of the array. The result for an array will be an
array with the keys preserved, in the same order. Any multi-dimensions are
also respected and returned within the array.

This is the same as using the array_slice method with the PRESERVE KEYS
fourth parameter passed through as true.

The result for a string is the string from the two positions indicated.
This is the same as using `substr()`.

The benefits for this as I see it is:

1) No function overhead
2) More readable (opinionated)
3) Consistent with how we can select items from an array currently (using
index).

If the array is not long enough (for example, index 4 doesn't exist), then
a NOTICE is thrown, and the values returned are as much as possible; this
would be the same as calling $array[1:] which will get the items in
position 1 through to the end.

If the variable used contains a string, then this will get the values from
the string at those positions. The same way that $string[1] will get the
second character, $string[2:5] will get the third through to the sixth
character. This differs from array_slice which would throw a warning and
return null.

If the variable isn't either a string or an array (or convertible to
either); then a warning is thrown and null is returned, consistent with
current use ($int[0] will return null)

Arrays with associated keys cannot be selected by using the keys they have,
but instead should be selected by the position those keys hold.

For example, this is invalid:

$array['string':'end']. This should throw a fatal error.

The valid options are:

$array[from:to] - This gets the values from position 'from' to 'to'
inclusive
$array[from:] - This gets the values from the position 'from' to the end.
$array[:to] - This gets the values from the start to the position 'to'.

$array[:] will get all the items in the array ($same as doing $array)

A side addition, that may be considered is adding [-1] to get the last item
in the array. But that is not a main part of this RFC.

Thanks

---

## #85240 — Larry Garfield — 2015-03-19T21:03:38+00:00

URL: https://externals.io/message/85238#85240 · In reply to: #85238

> This email is just to gauge the response for some syntactic sugar to be
> added to PHP in regard to slicing an array.
>
> My proposal is something similar to Pythons slice, in PHP this would look
> like:
>
> $slided = $array[1:4]
>
> This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),
> ignoring the actual key of the array. The result for an array will be an
> array with the keys preserved, in the same order. Any multi-dimensions are
> also respected and returned within the array.
>
> This is the same as using the array_slice method with the PRESERVE KEYS
> fourth parameter passed through as true.
>
> The result for a string is the string from the two positions indicated.
> This is the same as using `substr()`.
>
> The benefits for this as I see it is:
>
> 1) No function overhead
> 2) More readable (opinionated)
> 3) Consistent with how we can select items from an array currently (using
> index).
>
> If the array is not long enough (for example, index 4 doesn't exist), then
> a NOTICE is thrown, and the values returned are as much as possible; this
> would be the same as calling $array[1:] which will get the items in
> position 1 through to the end.
>
> If the variable used contains a string, then this will get the values from
> the string at those positions. The same way that $string[1] will get the
> second character, $string[2:5] will get the third through to the sixth
> character. This differs from array_slice which would throw a warning and
> return null.
>
> If the variable isn't either a string or an array (or convertible to
> either); then a warning is thrown and null is returned, consistent with
> current use ($int[0] will return null)
>
> Arrays with associated keys cannot be selected by using the keys they have,
> but instead should be selected by the position those keys hold.
>
> For example, this is invalid:
>
> $array['string':'end']. This should throw a fatal error.
>
> The valid options are:
>
> $array[from:to] - This gets the values from position 'from' to 'to'
> inclusive
> $array[from:] - This gets the values from the position 'from' to the end.
> $array[:to] - This gets the values from the start to the position 'to'.
>
> $array[:] will get all the items in the array ($same as doing $array)
>
> A side addition, that may be considered is adding [-1] to get the last item
> in the array. But that is not a main part of this RFC.
>
> Thanks


Variations of this proposal have been discussed many times.  I don't 
recall what the pushback was but it's worth your time to check the 
archives to see what the objections were and if you can address them, 
and/or if the new engine in PHP 7 addresses them.  (I suspect it 
has/will ameliorate a lot of implementation-level issues with old 
proposals.)

Personally I'd be in favor of such a syntax but I don't recall the 
objections in the past beyond "meh, sugar".

--Larry Garfield

---

## #85241 — Alex Bowers — 2015-03-19T21:06:54+00:00

URL: https://externals.io/message/85238#85241 · In reply to: #85240

I've had a quick scan of the list at https://wiki.php.net/rfc but cannot
seem to find anything. I'll read more carefully through, or is there a
different list elsewhere which I should look at?




> 
>
> > […]
>
>
> Variations of this proposal have been discussed many times.  I don't
> recall what the pushback was but it's worth your time to check the archives
> to see what the objections were and if you can address them, and/or if the
> new engine in PHP 7 addresses them.  (I suspect it has/will ameliorate a
> lot of implementation-level issues with old proposals.)
>
> Personally I'd be in favor of such a syntax but I don't recall the
> objections in the past beyond "meh, sugar".
>
> --Larry Garfield

---

## #85243 — Larry Garfield — 2015-03-19T21:11:47+00:00

URL: https://externals.io/message/85238#85243 · In reply to: #85241

> I've had a quick scan of the list at https://wiki.php.net/rfc but cannot
> seem to find anything. I'll read more carefully through, or is there a
> different list elsewhere which I should look at?

Not everything makes it to an RFC.  This list's archives are quite 
extensive.  (People here are verbose):

http://php.net/mailing-lists.php
http://marc.info/?l=php-internals

Also, no top-posting, please.

--Larry Garfield

---

## #85244 — Alex Bowers — 2015-03-19T21:15:26+00:00

URL: https://externals.io/message/85238#85244 · In reply to: #85243

> 
>
> > […]
>
> Not everything makes it to an RFC.  This list's archives are quite
> extensive.  (People here are verbose):
>
> http://php.net/mailing-lists.php
> http://marc.info/?l=php-internals
>
> Also, no top-posting, please.
>
> --Larry Garfield
>
> --
> 
> 
>
>
Apologies about the top post, that was gmail automatically hiding the main
content so I just typed. Thanks for the links. I will look through them now
to find some proposals which have failed before; and try to improve this
one. Still would like feedback from anybody else reading this too. Thanks.

---

## #85249 — Rowan Collins — 2015-03-19T23:23:45+00:00

URL: https://externals.io/message/85238#85249 · In reply to: #85238

> My proposal is something similar to Pythons slice, in PHP this would look
> like:
>
> $slided = $array[1:4]
>
> This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),
> ignoring the actual key of the array. The result for an array will be an
> array with the keys preserved, in the same order.

While I can see the reasoning for not looking into the actual keys 
(which might not have a logically sliceable order), I think the syntax 
needs to be more distinct, because this seems a bit confusing:

$countdown = [ 5 => 'Five!', 4 => 'Four!', 3 => 'Three!', 2 => 'Two!', 1 
=> 'One!', 0 => 'Zero!' ]

$countdown[0]; // 'Zero!'
$countdown[0:0]; // ['Five!']
$countdown[0:][0] // 'Zero!'
$countdown[:0][0] // null - slice contains no key 0

The problem is that the slice access looks like an extension of key 
access, but is actually a new concept of positional element access. With 
a slight tweak to syntax, such as adding an @, we could make positional 
access available for non-slices as well:

reset($countdown); // Five! - a common way of getting the first element 
positionally
$countdown[@0]; // 'Five!'
$countdown[@1]; // 'Four!'
$countdown[@0:0] // ['Five!']
$countdown[@0:1] // ['Five!', 'Four!']
$countdown[@0:][@0] // 'Five!'
$countdown[@:0][@0] // 'Five!'


> A side addition, that may be considered is adding [-1] to get the last item
> in the array. But that is not a main part of this RFC.

This would actually be a really important addition for me, but only if I 
can do it on a non-slice, as above:

$countdown[-1]; // null - no such key
end($countdown); // 'Zero!'  - common way of getting last element
$countdown[@-1]; // 'Zero!' - positional access counting from the end
$countdown[@-2]; // 'One!' - fiddly to do in current PHP


I just wrote out all those examples and realised that it may not be 
possible to reuse @ in this context. Finding new symbols to use for 
syntax is hard. :(

Regards,

-- 
Rowan Collins
[IMSoP]

---

## #85250 — Alex Bowers — 2015-03-19T23:55:19+00:00

URL: https://externals.io/message/85238#85250 · In reply to: #85249

> 
>
> > […]
>
> While I can see the reasoning for not looking into the actual keys (which
> might not have a logically sliceable order), I think the syntax needs to be
> more distinct, because this seems a bit confusing:
>
> $countdown = [ 5 => 'Five!', 4 => 'Four!', 3 => 'Three!', 2 => 'Two!', 1
> => 'One!', 0 => 'Zero!' ]
>
> $countdown[0]; // 'Zero!'
> $countdown[0:0]; // ['Five!']
> $countdown[0:][0] // 'Zero!'
> $countdown[:0][0] // null - slice contains no key 0
>
> The problem is that the slice access looks like an extension of key
> access, but is actually a new concept of positional element access. With a
> slight tweak to syntax, such as adding an @, we could make positional
> access available for non-slices as well:
>
> reset($countdown); // Five! - a common way of getting the first element
> positionally
> $countdown[@0]; // 'Five!'
> $countdown[@1]; // 'Four!'
> $countdown[@0:0] // ['Five!']
> $countdown[@0:1] // ['Five!', 'Four!']
> $countdown[@0:][@0] // 'Five!'
> $countdown[@:0][@0] // 'Five!'
>
>
>  A side addition, that may be considered is adding [-1] to get the last
> > […]
>
> This would actually be a really important addition for me, but only if I
> can do it on a non-slice, as above:
>
> $countdown[-1]; // null - no such key
> end($countdown); // 'Zero!'  - common way of getting last element
> $countdown[@-1]; // 'Zero!' - positional access counting from the end
> $countdown[@-2]; // 'One!' - fiddly to do in current PHP
>
>
> I just wrote out all those examples and realised that it may not be
> possible to reuse @ in this context. Finding new symbols to use for syntax
> is hard. :(
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> 
> 
>
>
While I can see the reasoning for not looking into the actual keys (which
> might not have a logically sliceable order), I think the syntax needs to be
> more distinct, because this seems a bit confusing:
> $countdown = [ 5 => 'Five!', 4 => 'Four!', 3 => 'Three!', 2 => 'Two!', 1
> => 'One!', 0 => 'Zero!' ]
> $countdown[0]; // 'Zero!'
> $countdown[0:0]; // ['Five!']
> $countdown[0:][0] // 'Zero!'
> $countdown[:0][0] // null - slice contains no key 0
>

Thats a good point, something else that just came to me; your example of
$countdown[0:0]; if we had it as inclusive indexes, then this would
actually give you ['Five!', 'Five!'], which is unlikely to be what was
desired. What would be a good solution to this?

1) The range cannot be 0 in length (such that, from - to must be > 0) -
This would also get around issues of people trying to use it like so :
$countdown[5:3], as the expected outcome of that should be a fatal error.
Also, your use-case of 0:0 would be better placed simply using
$countdown[0].

The issue with this solution would then come that  if there was any code
for this range being dynamic, some logic would have to take place on the
users side to ensure that $from and $to differ by at least +1

To me, this isn't really a big issue, since I cannot see this being that
big of a use case, but it is worth mentioning.

To me, a larger use case would be a user wanting say, the first N items
from an array, and so using $sub_array = $array[: (N-1)], which can then be
easily used within a foreach loop, without the need for $key to be used and
breaking out of the foreach loop on the Nth iteration.

The problem is that the slice access looks like an extension of key access,
> but is actually a new concept of positional element access. With a slight
> tweak to syntax, such as adding an @, we could make positional access
> available for non-slices as well:


I think the use of the @ symbol would be misplaced for this; it already has
a meaning within PHP, and many people are often taught to shy away from it
(due to previous bad coding practices using it heavily); and so this
feature might suffer by association even though the symbol means something
completely different.

A different symbol is certainly a possibility; but this is something that
happens nowhere else (ignoring the & by reference) in PHP, and feels like
it isn't the best solution to the problem.

Other languages that implement this do not require a prefixed symbol, and I
don't see the need for PHP to have one. There may be some confusion; but
that will be displaced over time.

2) Would a possible solution to this be just to make it explicitly clear in
the documentation that this *does not* refer to the keys, and instead the
array positions?

>
> > […]
> item
> > […]





>This would actually be a really important addition for me, but only if I
> can do it on a non-slice, as above:




To me, whilst I certainly want this part in it, I don't want to overload
the RFC with things that aren't core to the feature, which may be cause for
rejection if it makes it to a vote; I may do this as a successor-vote. Feel
free to make it its own RFC if you want.

---

## #85255 — Rowan Collins — 2015-03-20T01:02:01+00:00

URL: https://externals.io/message/85238#85255 · In reply to: #85250

> Thats a good point, something else that just came to me; your example 
> of $countdown[0:0]; if we had it as inclusive indexes, then this would 
> actually give you ['Five!', 'Five!'], which is unlikely to be what was 
> desired.

I'm not sure why it would duplicate the item like that. My 
interpretation of $array[$start:$end] would be "an array containing all 
those elements of $array with a position more than or equal to $start, 
but less than or equal to $end" ($position >= $start && $position <= $end).

Under that interpretation, $array[0:0] is a valid slice, of length 1, 
which would contain only the element of $array with position 0 (0 >= 0 
&& 0 <= 0).

Since you propose to preserve keys in the slice, it's actually 
impossible to have a duplicate item in the output anyway: if you were 
right and it selected the first item twice, you'd get [5 => 'Five!', 5 
=> 'Five!'], but keys are unique by definition, so it would end up 
stored as [5 => 'Five!'].


> 1) The range cannot be 0 in length (such that, from - to must be > 0) 
> - This would also get around issues of people trying to use it like so 
> : $countdown[5:3], as the expected outcome of that should be a fatal 
> error.

$countdown[0:0] is a slice of length 1, not 0, just as $countdown[0:1] 
is a slice of length 2, not 1. Under my proposed definition, 
$countdown[5:3] could simply always return an empty array, since there 
is no value of $position such that ($position >= 5 && $position <= 3).


> Also, your use-case of 0:0 would be better placed simply using 
> $countdown[0].

Check my example again. $countdown[0] refers to the element with key 0, 
so is absolutely not a replacement for $countdown[0:0]. This is the 
whole point of my example.



> I think the use of the @ symbol would be misplaced for this

To be clear, @ was just the first idea that came to mind, not central to 
my point. The point is to first create syntax for "positional access", 
and then extend that to "positional slice access".


> A different symbol is certainly a possibility; but this is something 
> that happens nowhere else (ignoring the & by reference) in PHP, and 
> feels like it isn't the best solution to the problem.

I'm not sure what you mean by "something that happens nowhere else" PHP 
has syntax for all sorts of things, using all sorts of symbols. Your own 
suggestion uses the : symbol in a place where it currently can't exist.


> Other languages that implement this do not require a prefixed symbol, 
> and I don't see the need for PHP to have one.

Most languages don't need to worry about an "array" type which has keys 
independent from their position. PHP is the only language I know where 
the 0 in $foo[0] does not refer to the position in the array, but a key 
which can appear at any position.


> 2) Would a possible solution to this be just to make it explicitly 
> clear in the documentation that this *does not* refer to the keys, and 
> instead the array positions?

To my mind, no. Manual pages about syntax features are hard to find 
unless you know exactly what that syntax feature is called, and 
documenting an inconsistency is no substitute for avoiding that 
inconsistency in the first place.

Regards,

-- 
Rowan Collins
[IMSoP]

---

## #85258 — Alex Bowers — 2015-03-20T01:28:53+00:00

URL: https://externals.io/message/85238#85258 · In reply to: #85255

>
> I'm not sure why it would duplicate the item like that. My interpretation
> of $array[$start:$end] would be "an array containing all those elements of
> $array with a position more than or equal to $start, but less than or equal
> to $end" ($position >= $start && $position <= $end).
>

I agree with this statement now, I was misinterpreting how I thought it
should work, but reading this; I think you're right. Also, your next point
about the unique array indexes covers it anyway, so it doesn't really
matter regardless.

Check my example again. $countdown[0] refers to the element with key 0, so
> is absolutely not a replacement for $countdown[0:0]. This is the whole
> point of my example.


You're correct, this was my mistake.

I'm not sure what you mean by "something that happens nowhere else" PHP has
> syntax for all sorts of things, using all sorts of symbols. Your own
> suggestion uses the : symbol in a place where it currently can't exist.


What I mean by 'symbol' here, is a prefix to tell it what the context of
its use is; in this case, it is the declaration that we are requiring the
index not the key. As far as I'm aware, and can think of at the moment, PHP
has nothing like a hinter symbol.

The only purpose of this symbol is to tell the user that it is indexes not
keys.

Maybe there should be a symbol to declare that, but i'm not sure. Will
appreciate more comments on this.

If we go the direction of using a symbol, what should be the outcome of the
symbol missing? fatal error, or to try to slice based on the keys?

---

## #85268 — Rowan Collins — 2015-03-20T09:10:10+00:00

URL: https://externals.io/message/85238#85268 · In reply to: #85258

>I'm not sure what you mean by "something that happens nowhere else" PHP
>has
> > […]
>exist.
>
>
>What I mean by 'symbol' here, is a prefix to tell it what the context
>of
>its use is; in this case, it is the declaration that we are requiring
>the
>index not the key. As far as I'm aware, and can think of at the moment,
>PHP
>has nothing like a hinter symbol.
>
>The only purpose of this symbol is to tell the user that it is indexes
>not
>keys.

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.

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.

Similarly, your suggested slice syntax is chosen to look similar to key access, and to the same feature in other languages, but since it doesn't exist yet, we can make up whatever parser rules we want.


>Maybe there should be a symbol to declare that, but i'm not sure. Will
>appreciate more comments on this.
>
>If we go the direction of using a symbol, what should be the outcome of
>the
>symbol missing? fatal error, or to try to slice based on the keys?

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.

You could implement slicing on keys, and if you did so, [x:y] would be the obvious syntax to use, but as you've said of negative positions, let's keep to one feature at a time.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #85271 — Leigh — 2015-03-20T10:38:22+00:00

URL: https://externals.io/message/85238#85271 · In reply to: #85240

> Variations of this proposal have been discussed many times.  I don't
> recall what the pushback was but it's worth your time to check the archives
> to see what the objections were and if you can address them, and/or if the
> new engine in PHP 7 addresses them.  (I suspect it has/will ameliorate a
> lot of implementation-level issues with old proposals.)
>

I've tried implementing python style slice on both strings and arrays in
the past (I don't seem to have an existing branch with it in any more
though it seems). The biggest problems I hit were regarding the syntax, the
functionality itself worked.

Colons caused problems with ternary operators in the lexer, and I had an
issue with commas too, but I forget what it was. Of course these might have
been resolvable, but I didn't put too much effort into it.

---

## #85272 — Leigh — 2015-03-20T10:43:21+00:00

URL: https://externals.io/message/85238#85272 · In reply to: #85271

>
> I've tried implementing python style slice on both strings and arrays in
> the past (I don't seem to have an existing branch with it in any more
> though it seems). The biggest problems I hit were regarding the syntax, the
> functionality itself worked.
>
> Colons caused problems with ternary operators in the lexer, and I had an
> issue with commas too, but I forget what it was. Of course these might have
> been resolvable, but I didn't put too much effort into it.
>

 That said, I'm a little older and wiser than I was then, I'd still be
interested in looking at this. I'll try and come up with _something_ that
works over the weekend.

---

## #85273 — Alex Bowers — 2015-03-20T11:38:35+00:00

URL: https://externals.io/message/85238#85273 · In reply to: #85268

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

---

## #85274 — Alex Bowers — 2015-03-20T11:40:17+00:00

URL: https://externals.io/message/85238#85274 · In reply to: #85271

>
> I've tried implementing python style slice on both strings and arrays in

the past (I don't seem to have an existing branch with it in any more
> though it seems). The biggest problems I hit were regarding the syntax, the
> functionality itself worked.


If you've got a link to your messaging thread, I'd love to read it. Thanks

Colons caused problems with ternary operators in the lexer, and I had an
> issue with commas too, but I forget what it was. Of course these might have
> been resolvable, but I didn't put too much effort into it.


Could this not be mitigated by adding a new token like T_COLON to be used
to match this use case?

---

## #85275 — Alex Bowers — 2015-03-20T11:44:25+00:00

URL: https://externals.io/message/85238#85275 · In reply to: #85272

>
> That said, I'm a little older and wiser than I was then, I'd still be
> interested in looking at this. I'll try and come up with _something_ that
> works over the weekend.


I started on the code last night, but didn't get very far. I got it to
match the T_COLON, but no logic or parsing has been done yet. I am still a
bit shaky on how to implement this, so would definitely appreciate the help

---

## #85278 — Rowan Collins — 2015-03-20T12:24:22+00:00

URL: https://externals.io/message/85238#85278 · In reply to: #85273

Alex Bowers wrote on 20/03/2015 11:38:
>
>     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.

Yep, I think we're on the same page now.

There's basically three ways of selecting items - by key, by position 
from start, and by position from end - and two types of selection - a 
single element, or an array of zero or more elements. That gives us 6 
possible combinations, which (using the @ notation for consistency with 
previous examples) would be:

Select by key:
Single element: $array[$x]  - existing syntax
Slice: $array[$a:$b] - equivalent to a filter asserting $key >= $a && 
$key <= $b

Select by position from start:
Single element: $array[@$x]
Slice: $array[@$a:$b],$array[@$a:], and $array[@:$b]

Select by position from end - as above, but using negative indexes:
Single element: $array[@-$x] - equivalent to $array[@length($array)-$x]
Slice: $array[@-$a:-$b] - equivalent to 
$array[@length($array)-$a:length($array)-$b]


Several of these are actually rather hard to do with current PHP features:
- you can get the first element with `reset()` and the last with `end()`, 
but arbitrary position selection is harder
- there is no version of array_filter for testing keys, and being able 
to write $dictionary['elephant':'snake'] would actually be pretty handy

Actually, the only one that's easy to emulate (apart from the obvious 
single element by key) is the one you propose to add first - getting a 
positional slice of an array, which array_slice(..., true) already does.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #85279 — Leigh — 2015-03-20T12:26:06+00:00

URL: https://externals.io/message/85238#85279 · In reply to: #85274

> > […]
the
> > […]
>
>
> If you've got a link to your messaging thread, I'd love to read it. Thanks
>
> > […]
have
> > […]
>
>
> Could this not be mitigated by adding a new token like T_COLON to be used
to match this use case?

The only thing I could find is:
http://chat.stackoverflow.com/transcript/11?m=15926856#15926856

If your branch is available on github let me know, more than happy work on
it with you.

---

## #85280 — Alex Bowers — 2015-03-20T12:32:45+00:00

URL: https://externals.io/message/85238#85280 · In reply to: #85278

We also need to consider then the possibility of setting data by position.

What should $array[@1:3]  = [1,2,3] do?

Should it overwrite the values there, and append any that don't exist, or
should it be a parse error?

---

## #85281 — Alex Bowers — 2015-03-20T12:33:24+00:00

URL: https://externals.io/message/85238#85281 · In reply to: #85279

>
> If your branch is available on github let me know, more than happy work on
> it with you.


I'll publish it tonight (GMT), I'm at work at the moment.

Thanks!

---

## #85282 — Leigh — 2015-03-20T12:37:10+00:00

URL: https://externals.io/message/85238#85282 · In reply to: #85280

>
> We also need to consider then the possibility of setting data by position.
>
> What should $array[@1:3]  = [1,2,3] do?
>
> Should it overwrite the values there, and append any that don't exist, or
> should it be a parse error?

I'd say overwrite/replace the range with the new value.

---

## #85283 — Rowan Collins — 2015-03-20T13:04:36+00:00

URL: https://externals.io/message/85238#85283 · In reply to: #85280

Alex Bowers wrote on 20/03/2015 12:32:
> We also need to consider then the possibility of setting data by position.
>
> What should $array[@1:3]  = [1,2,3] do?
>
> Should it overwrite the values there, and append any that don't exist, 
> or should it be a parse error?
>

Good catch. I guess it could delete the range and replace with the new 
value, regardless of size - then you could remove elements from an array 
with it, too:

$array[@1:3] = []; // Remove the second through fourth element
$array['x':'z'] = []; // Remove all elements with keys between 'x' and 
'z', inclusive

Not sure how that compares to other languages with similar syntax.

It would be kind of cool if it applied to string subscripts as well:

$version = 'PHP 5.6.1';
$version{4:} = '7!';
echo $version; // 'PHP 7!'

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #85284 — Alex Bowers — 2015-03-20T13:09:05+00:00

URL: https://externals.io/message/85238#85284 · In reply to: #85283

> $version{4:} = '7!';


I'm sure this is a slight oversight on your end, but just to check. The
change of using {} instead of [] is not because its a string, and is just a
typo / example correct?

---

## #85285 — Alex Bowers — 2015-03-20T13:10:11+00:00

URL: https://externals.io/message/85238#85285 · In reply to: #85283

>
> $array['x':'z'] = []; // Remove all elements with keys between 'x' and
> 'z', inclusive


I believe i mentioned in the past about strings not being allowed for
ranges, since there is no real way to check this (and this appears to be by
key not by index) which should be a separate RFC thread, assuming this one
gets accepted to be expanded upon.





> Alex Bowers wrote on 20/03/2015 12:32:
>
> > […]
> Good catch. I guess it could delete the range and replace with the new
> value, regardless of size - then you could remove elements from an array
> with it, too:
>
> $array[@1:3] = []; // Remove the second through fourth element
> $array['x':'z'] = []; // Remove all elements with keys between 'x' and
> 'z', inclusive
>
> Not sure how that compares to other languages with similar syntax.
>
> It would be kind of cool if it applied to string subscripts as well:
>
> $version = 'PHP 5.6.1';
> $version{4:} = '7!';
> echo $version; // 'PHP 7!'
>
> Regards,
> --
> Rowan Collins
> [IMSoP]

---

## #85286 — Rowan Collins — 2015-03-20T13:17:32+00:00

URL: https://externals.io/message/85238#85286 · In reply to: #85284

Alex Bowers wrote on 20/03/2015 13:09:
>
> On 20 March 2015 at 13:04, Rowan Collins <rowan.collins@gmail.com 
> <mailto:rowan.collins@gmail.com>> wrote:
>
>     $version{4:} = '7!';
>
>
> I'm sure this is a slight oversight on your end, but just to check. 
> The change of using {} instead of [] is not because its a string, and 
> is just a typo / example correct?

It's an alternative syntax, which I thought was only usable for string 
indexing [1] but is apparently legal on arrays as well [2].

I personally like the idea of string offsets having similar but slightly 
different syntax from array offsets, to make clear which you're using. I 
use {} instead of [] for that reason, but at the moment the syntaxes are 
completely interchangeable as far as I can tell.

[1] 
http://php.net/manual/en/language.types.string.php#language.types.string.substr
[2] 
http://php.net/manual/en/language.types.array.php#language.types.array.syntax.accessing

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #85288 — Rowan Collins — 2015-03-20T13:21:07+00:00

URL: https://externals.io/message/85238#85288 · In reply to: #85285

Alex Bowers wrote on 20/03/2015 13:10:
>
>     $array['x':'z'] = []; // Remove all elements with keys between 'x'
>     and 'z', inclusive
>
>
> I believe i mentioned in the past about strings not being allowed for 
> ranges, since there is no real way to check this (and this appears to 
> be by key not by index) which should be a separate RFC thread, 
> assuming this one gets accepted to be expanded upon.

I'm carrying over my syntax from previous examples - [a:b] meaning a 
key-based slice (which implies accepting string keys, because there's no 
reason not to) vs [@a:b] meaning a positional slice. See my earlier mail 
on the 6 different types of access - I do realise you're not planning to 
implement them all, just playing with the implications of different 
decisions if we carry them through consistently in the future.

Regards,
-- 
Rowan Collins
[IMSoP]

---

Next page: https://externals.io/message/85238.md?page=2