I don’t think “how it works” is the confusion, more of “how to use it properly”
My opinion is that if RTFM is required more than once for a core concept there may be a design problem. It clearly bites a lot of people. Slices are a higher level struct, as the underlying array is the same as Java, but Java doesn’t suffer these knowledge gaps. I’m guessing because it’s higher but not high enough. Done for performance while forsaking some safety and clarity. > On Jun 26, 2020, at 12:28 PM, howardcs...@gmail.com wrote: > > > "If the capacity of s is not large enough to fit the additional values, > append allocates a new, sufficiently large underlying array that fits both > the existing slice elements and the additional values. Otherwise, append > re-uses the underlying array." > > That seems pretty explicit to me? That's from the spec, the other link above, > the blog, is even more explicit, by straight up showing the implementation > before introducing the built-in. > > The tour also says it: https://tour.golang.org/moretypes/15 > "If the backing array of s is too small to fit all the given values a bigger > array will be allocated. The returned slice will point to the newly allocated > array." > > It also links to this documentation: https://blog.golang.org/slices-intro > "The append function appends the elements x to the end of the slice s, and > grows the slice if a greater capacity is needed." - this is the only one that > seems less than explicit about the semantics, and in the sense that it does > not make explicit that 'grows the slice' means 'returns a copy of the slice > with greater capacity.' > > > The latter link then links further to this documentation: > https://golang.org/doc/effective_go.html#slices > and just like the blog, it starts by introducing the implementation, where it > is clear that only one path includes a copy function, and it explicitly says > "If the data exceeds the capacity, the slice is reallocated." A bit later > where it covers append directly, it says "The result needs to be returned > because, as with our hand-written Append, the underlying array may change." > > 4 bits of official documentation, all of which mention the 'gotcha' more or > less directly. And in most of those cases, discussion of append directly > follows discussion of 'copy', which should make it clear how to get copies of > slices. > > I think maybe where it gets missed is from people learning the language by > example, by coping code from StackOverflow, reading code in GitHub, etc. Go > is pretty surprisingly easy to pick up by example like that, but it does mean > those corner cases can bite - however, the actual documentation is pretty > clear and up-front about the gotchas. > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/f98d538e-55d5-4a61-b7d2-1ab9497d3cd5o%40googlegroups.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/B7116805-340B-4F43-A7F3-69B3A8D71011%40ix.netcom.com.
