Slices - cap assymetry.

[lamvak]

It struck me today: the one thing that bothers me in otherwise ingenious construct of slices is their asymmetry.

One can safely extend slices to the right according to their caps. But why only to the right? It's asymmetrical.

It would be quite nice - useful at times, yes, but also elegant - if one would have cap-range instead of cap and would be able to extend the slice the the left as well as to the right.

Now, extending a slice to the right does not change present element indexing. And the same should hold for extending to the left. That being said, it's only logical to have negative indexes for the left extended part.

How do you find the idea?

[Peter S]

There is a recent thread about negative indexes for arrays/slices:

https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/iWFKqtMDnDY

I agree with Kyle that this is not commonly needed so it is better implemented as a separate package.

Peter

[lamvak]

I admit I forgot to make a redundancy check before hitting publish, but in this particular case I would argue that it's not a redundancy.

The other proposition is more than just a negative indexes, whereas I propose only one thing: give us the other half of slice's capabilities ;). I imagine that even the code could be symmetrical, so it's not much of a new idea in fact, only a systematic conclusion.

[Kyle Lemons]

On Sat, Jul 7, 2012 at 1:13 AM, lamvak <lam...@gmail.com> wrote:

I admit I forgot to make a redundancy check before hitting publish, but in this particular case I would argue that it's not a redundancy.

The other proposition is more than just a negative indexes, whereas I propose only one thing: give us the other half of slice's capabilities ;). I imagine that even the code could be symmetrical, so it's not much of a new idea in fact, only a systematic conclusion.

I can't think of a way to implement this that doesn't make slice bounds checking slower.  Considering it's currently done with (if I recall) 5 CPU instructions, adding (conservatively; I'm not sure you could do it in as few as) two more instructions for every single (non-range) slice index operation would be a dramatic performance hit for what I think can be safely characterized as a rare use case.

[Jan Mercl]

On Sat, Jul 7, 2012 at 9:35 AM, lamvak <lam...@gmail.com> wrote:

How do you find the idea?

Currently slices (the value, not the backing array) are a 3-word beast: {ptr, len, cap}. The proposal would require every instance of them to became 33% bigger, e.g.: {&items[0], firstIndex, len, cap}. Slices are used a lot in G programs, so there would be, among other possibilities, also unwelcome performance issues due to passing around, now a bigger, struct hiding the slice internals.

-j