Hi Ian, On Mon, Jun 27, 2016 at 8:18 PM, Ian Lance Taylor <i...@golang.org> wrote: > On Sun, Jun 26, 2016 at 10:55 PM, Dan Kortschak > <dan.kortsc...@adelaide.edu.au> 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.
