After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 571352 - Support for array[N:M] syntax
Support for array[N:M] syntax
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Arrays
unspecified
Other All
: Normal enhancement
: 1.2
Assigned To: Vala maintainers
Vala maintainers
: 641268 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-02-11 21:27 UTC by Zeeshan Ali
Modified: 2018-05-22 13:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Initial support for array slices (16.95 KB, patch)
2009-12-16 09:56 UTC, Robin Sonefors (ozamosi)
committed Details | Review
Support negative array/slice indices (3.37 KB, patch)
2010-03-22 09:03 UTC, Robin Sonefors (ozamosi)
none Details | Review
Allow empty start or stop value in array slices (8.16 KB, patch)
2010-03-22 09:08 UTC, Robin Sonefors (ozamosi)
none Details | Review
Validate array indices for element accesses and slices (3.17 KB, patch)
2010-03-22 09:14 UTC, Robin Sonefors (ozamosi)
none Details | Review

Description Zeeshan Ali 2009-02-11 21:27:57 UTC
It will be really nice if vala supports array[N:M] syntax for easy slicing for arrays.
Comment 1 Michael 'Mickey' Lauer 2009-10-07 13:43:35 UTC
Let me toss an additional vote for this feature, and if possible, also add negative indices, as per Python syntax. The icing on the cake then would be array[N:M:S], with S being the step.
Comment 2 Robin Sonefors (ozamosi) 2009-12-16 09:56:57 UTC
Created attachment 149820 [details] [review]
Initial support for array slices

I've done some work on this, and I'd like some feedback before I continue — if this has no chance of being accepted, I'd rather stop now, rather than after even more coding.

I used the perl/ruby/D notation, so slices are specified with double periods instead of colons, so it's array[N..M]. I'm not sure if the other syntax is preferable, but if so, it'd be easy to switch.

=> Things that are done:
Slicing works for strings, and for one dimensional arrays. Non-pure expressions can be used to specify the slice size.

=> Things that need work:
Slicing for multi dimensional arrays do not work.

There is no slicing for signal handlers.

Slices of slices (like array[N..M][P..Q]) generates very broken code (array2=array[N..M];array2[P..Q] works though — I'm just failing to put the right function calls in the right place).

There's no documentation, and no support for genie.

There's no step parameter, and no negative indices.

This is the first time I've looked at the Vala code (or any compiler's code), so there'll probably be some restructuring required.
Comment 3 Marc-Andre Lureau 2009-12-16 10:24:37 UTC
nice!
Comment 4 Jürg Billeter 2009-12-19 08:53:53 UTC
Thanks for the patch. I think we should use the Python syntax as in the range syntax the end is usually inclusive, and I'd prefer an exclusive end index. Your implementation uses the range syntax with an exclusive end index, which is rather uncommon, as far as I can tell.

We can probably simplify the string implementation by adding a slice method to glib-2.0.vapi and just call that to avoid complex C code generation. At the same time, this would allow us to make the slice syntax more flexible as it could be supported for any type that has a slice method, as, for example, Gee.ArrayList.
Comment 5 Jürg Billeter 2009-12-19 09:01:47 UTC
commit 0a692ab35788c14498127ca8c04d144a6616ae57
Author: Jürg Billeter <j@bitron.ch>
Date:   Sat Dec 19 10:00:36 2009 +0100

    glib-2.0: Add string.slice method
Comment 6 Jürg Billeter 2009-12-19 11:09:57 UTC
commit 52d84048e075bba00f59992a373e1de954fa2b60
Author: Jürg Billeter <j@bitron.ch>
Date:   Sat Dec 19 12:02:05 2009 +0100

    Initial support for array slices
    
    Add support for slice expressions such as array[1:5] to retrieve a
    slice of length 4 starting at the second element of the array. Slice
    expressions are also supported for strings and other types that provide
    an appropriate slice method.
    
    Based on patch by Robin Sonefors, fixes bug 571352.
Comment 7 Michael 'Mickey' Lauer 2010-03-14 09:18:18 UTC
Reopening this and flagging as enhancements as per the following enhancements / fixes:

1.) Negative slice indices
It would be much more convenient to say
var foo = bar[4:-1] as opposed to var foo = bar[4:bar.length-1];

I'd appreciate if this syntax could even be used for normal index lookup, getting the last element in an array looks much better via bar[-1] than bar[bar.length-1];

2.) Range check semantics.
Right now you can allocated invalid slices, which should be forbidden, i.e.

void main()
{
        var array = new char[] { 'H', 'A', 'L', 'L', 'O' };
        var slice = array[2:100];
        message( @"slice length = $(slice.length)" );
}

Here we are able to get a slice with the length 98 out of 5, which should clearly be not allowed, it should be truncated to the actual maximum size.
Comment 8 Robin Sonefors (ozamosi) 2010-03-22 09:03:47 UTC
Created attachment 156722 [details] [review]
Support negative array/slice indices

This was already supported for string slices, but now it works for array slices and element accesses as well.

This is the first patch in a series of three with various improvements to the slice support. Please note that they'll have to be applied in the order I upload them.
Comment 9 Robin Sonefors (ozamosi) 2010-03-22 09:08:40 UTC
Created attachment 156723 [details] [review]
Allow empty start or stop value in array slices

Empty stop values allows a more convenient way to express "the rest
of the array" (a[n:] vs a[n:a.length]). Empty start values provides
nice symmetry.
Comment 10 Robin Sonefors (ozamosi) 2010-03-22 09:14:52 UTC
Created attachment 156724 [details] [review]
Validate array indices for element accesses and slices

Modeled on the tests in the slice method in the string class, but
checks that slice end > slice start is not yet implemented.
Comment 11 Jürg Billeter 2010-03-26 09:49:42 UTC
Thanks for the patches. Even though strings already support slices with negative indices, I'm not sure whether it's really a good idea to support it. I understand that it can be convenient in quite some places, however, there are also some issues to consider:
 * Negative array indices are already supported for pointers but there they have a different meaning
 * As there is no difference between 0 and -0, there is some inconsistency here
 * When the index you use is the result of arithmetic operations, you might accidentally end up with negative values and this may result in hard to find bugs (or non-negative values such as 0 even though you intend to count from the end of the string)
 * As it needs to be checked at runtime, there is a performance penalty (might not be significant)

The same arguments apply to some extent to the proposal of truncating slices instead of reporting an error (which is not yet in these patches, if I read them correctly).

As I understand that it can be useful, I'm open for suggestions how this could be supported without the above issues. One possibility would be to have a separate token that represents the array length. That is, support something like the following:

int[] array = ...;
array[$-1] = 42; // assigns last element
var a = array[5:$]; // slice from 6th to last element
var b = array[$-5:$]: // last 5 elements

This would even be more flexible than the current proposal, although I'm not sure whether that part is really useful:

var c = array[0:$/2]; // first half of the array
var d = array[$/2:$]; // second half of the array

Maybe anyone else has better suggestions along the same line?

Allowing empty start or stop value in slices sounds like a good idea to me, and, in general, I don't see a reason why we shouldn't support it. However, if we implemented something like the above $ solution, we might want to skip it as $ would already cover the same use case, and I try to avoid syntax alternatives where it doesn't add anything.

BTW: At least the first patch behaves incorrectly if the passed array index is an expression with side effects.
Comment 12 Michael 'Mickey' Lauer 2010-03-26 11:37:59 UTC
I don't think the $ is particular comprehensible -- other than resembling a vague similarity to the end-of-line symbol in regex, but I could live with it, if it's the only chance to get this feature in.

I still think plain negative indices as well as 'missing' start/stop values would match the very clear syntax of Vala and be more readable.
Comment 13 Christian Dywan 2011-01-11 20:34:25 UTC
I find the $ syntax very hard to read. I think following Python syntax is really the better choice here. 

Would it be possible for valac to issue warnings if pointer arithmetic is used inside slice syntax to avoid ambiguity?
Comment 14 Michael 'Mickey' Lauer 2011-03-03 15:48:37 UTC
See also the related bugs #641268, #627460, and #641267. I still think following the Python syntax is the best approach.
Comment 15 Christian Dywan 2011-03-03 19:52:46 UTC
For what it's worth, I'm using slice() and substring() functions depending on the case at this point. Waiting very long with this new syntax unfortunately means in practise that it won't be usable for a very long time.
Comment 16 Marco Trevisan (Treviño) 2011-03-15 01:12:56 UTC
*** Bug 641268 has been marked as a duplicate of this bug. ***
Comment 17 GNOME Infrastructure Team 2018-05-22 13:18:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/26.