Re: [go-nuts] Append to slice... what happens?

[Ian Lance Taylor]

On Fri, Jul 1, 2016 at 2:42 AM, Martin Geisler  wrote:
>
> On Mon, Jun 27, 2016 at 8:18 PM, Ian Lance Taylor  wrote:
>> On Sun, Jun 26, 2016 at 10:55 PM, Dan Kortschak
>>  wrote:
>>> On Mon, 2016-06-27 at 07:49 +0200, Martin Geisler wrote:
 BTW, I was about to say that you could simplify the line one step
 further with

   b := append(a[::len(a)], 3, 4)

 but that gives a compilation error:

   prog.go:11: middle index required in 3-index slice

 I wonder what the rationale is for this? It seems inconsistent to me
 since the second (middle) index has a useful default (len(a)) that is
 used when there are only two indexes used.
>>>
>>> As I remember it, during the design discussions the possibility of using
>>> the shortened syntax you show above was considered, but rejected as an
>>> opening to bug entry (too much semantic weight on a single repeated
>>> character).
>>
>> Yes.  And, also, the default for the middle index is not wholly
>> obvious.  Should it be len(a) or (new) cap(a)?  In your example those
>> happen to have the same value, but of course in general they do not.
>
> Hmm, that's a good point that I hadn't considered :-) I figured it
> would be len(a) so that
>
>   a[x::z] = a[x:len(a):z]
>
> That keeps the defaults intact from normal 2-index slicing.
>
> For the indices to be in range, you must have z >= y where y = len(a).
> So maybe one could argue that the middle index y could be clamped at
> z, that is, the middle index y could be set to min(z, len(a)). That
> way you can have a slice with length 10 and still write
>
>   a[2::4] = a[2:min(4, 10):4] = a[2:4:4]
>
> where there indices are all in range.
>
> I see how this becomes more complicated than I initially thought... is
> that the kind of mess you were thinking of? :-)

Yes, that is an example.  If there is a default, it should be obvious
in all cases what the default should be.  If it's not obvious, there
shouldn't be a default.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Append to slice... what happens?

[Martin Geisler]

Hi Ian,

On Mon, Jun 27, 2016 at 8:18 PM, Ian Lance Taylor  wrote:
> On Sun, Jun 26, 2016 at 10:55 PM, Dan Kortschak
>  wrote:
>> On Mon, 2016-06-27 at 07:49 +0200, Martin Geisler wrote:
>>> BTW, I was about to say that you could simplify the line one step
>>> further with
>>>
>>>   b := append(a[::len(a)], 3, 4)
>>>
>>> but that gives a compilation error:
>>>
>>>   prog.go:11: middle index required in 3-index slice
>>>
>>> I wonder what the rationale is for this? It seems inconsistent to me
>>> since the second (middle) index has a useful default (len(a)) that is
>>> used when there are only two indexes used.
>>
>> As I remember it, during the design discussions the possibility of using
>> the shortened syntax you show above was considered, but rejected as an
>> opening to bug entry (too much semantic weight on a single repeated
>> character).
>
> Yes.  And, also, the default for the middle index is not wholly
> obvious.  Should it be len(a) or (new) cap(a)?  In your example those
> happen to have the same value, but of course in general they do not.

Hmm, that's a good point that I hadn't considered :-) I figured it
would be len(a) so that

  a[x::z] = a[x:len(a):z]

That keeps the defaults intact from normal 2-index slicing.

For the indices to be in range, you must have z >= y where y = len(a).
So maybe one could argue that the middle index y could be clamped at
z, that is, the middle index y could be set to min(z, len(a)). That
way you can have a slice with length 10 and still write

  a[2::4] = a[2:min(4, 10):4] = a[2:4:4]

where there indices are all in range.

I see how this becomes more complicated than I initially thought... is
that the kind of mess you were thinking of? :-)

-- 
Martin Geisler

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Append to slice... what happens?

[Martin Geisler]

Hi Henry,

On Mon, Jun 27, 2016 at 3:55 AM, Henry  wrote:
> If you were to change the code a bit as follows 
> https://play.golang.org/p/VwtWRQBrEe , it will work as you expect.
>
> I think it is probably safer to instantiate a slice without specifying the 
> initial capacity.

Having the capacity larger than the number of used elements (the
length of the slice) is indeed the problem. However, not specifying
the capacity can also fail you. Here I changed the numbers of elements
appended slightly and print the capacity after each operation:

  https://play.golang.org/p/WBTRvgJJKW

As you can see, append will over-allocate and set the capacity of the
underlying array to 4 when we go from an empty slice to a slice with
length 3. This in turn makes the following appends to a and b share
the 4th slot in the array and appending to a will ultimately update
the value you see in b.

In your example you were "lucky" since you started with a = [1, 2] and
cap(a) = 2. When you create b, append notices that the capacity is
exhausted and *creates a new underlying array for b*. After that step,
a and b are no longer "entangled" like this and updates to one cannot
affect the other.

-- 
Martin Geisler

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Append to slice... what happens?

[Henry]

If you were to change the code a bit as follows 
https://play.golang.org/p/VwtWRQBrEe , it will work as you expect. 

I think it is probably safer to instantiate a slice without specifying the 
initial capacity.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Append to slice... what happens?

[Jan Mercl]

On Mon, Jun 27, 2016 at 12:26 AM Peter Kleiweg  wrote:

> I don't know what I expected, but it's weird. Don't mess with slices.

Well, working as expected, considering slice backing array is possibly
shared wrt the result of append. (Or other slice op, b/c slices _are_
values.)

However, it's easy to avoid the append sharing when/where not desirable:
https://play.golang.org/p/oIFHamYWB-


-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Append to slice... what happens?

[Peter Kleiweg]

This:

https://play.golang.org/p/AE670rTMpE

I don't know what I expected, but it's weird. Don't mess with slices.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.