Hmmm, but in that first link you're updating the slice manually after the
append() -- that's exactly my point. The append() call can't touch the
caller's slice value (ptr, len, cap) because it's passed by value. So in
the code you wrote:
s := make([]int, 0, 10)
for i := 0; i < 10; i++ {
_ = append(s, i)
s = s[:i+1]
}
That "s = s[:i+1]" line is what's doing the appending and changing the
slice, not the append() call at all. It effectively just writes "i" to a
slot in the underlying array, as in "s[i] = i". Your code is doing part of
the append() with the extra "update s" line.
Hence the confusion. Sure, append can write to the underlying array because
that's effectively passed by reference. But it can't update the length of
the slice itself, unless you return it.
In short, append() needs to return a new slice (and the caller needs to use
it) not so much because "it may reallocate" but because you simply won't
get the new slice (ptr, len, cap) unless append() returns the new one by
value.
So the statement "We must return the slice afterwards because ... the slice
itself (the run-time data structure holding the pointer, length, and
capacity) is passed by value" makes good sense to me. The other two
statements seem confusing.
Does that make sense?
-Ben
On Sat, Nov 4, 2017 at 9:24 AM, Jan Mercl <0xj...@gmail.com> wrote:
> On Sat, Nov 4, 2017 at 1:53 PM Ben Hoyt <benh...@gmail.com> wrote:
>
> > It seems to me that the reasons given for why you need to use the return
> value of append() are confusing and not quite right. For example, at
> https://blog.golang.org/slices#TOC_9. Rob Pike says:
> >
> > "In this case it's especially important to return the slice, since when
> it reallocates the resulting slice describes a completely different array."
> >
> >
> > But (if I understand correctly) you need to return the slice *every*
> time, not because the slice reallocates, but because the slice is passed by
> value, so no changes
> > to the length will be reflected to the caller unless you return the new
> slice. It doesn't matter whether or not the underlying array has changed or
> been reallocated.
>
> Consider: https://play.golang.org/p/fMiZhQCVIt. It works perfectly while
> ignoring the result of append. If you s/10/11/ at line 9, it will fail.
> Compare to https://play.golang.org/p/Ohl8e6DmZy where the result of
> append is not ignored and it works for 11 elements just fine.
>
> So technically you don't need the result of append as long as the
> underlying array does not get reallocated and the cap is still sufficient
> (the same fact again, actually). IOW, Rob's quote above is correct and I'm
> not sure what confusion you do perceive about this.
>
> --
>
> -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.
