If you're fine with that then you should be upset by the subsequent example, because by your own definition "that's just not the way slices work".

▲

813ac4312b25c 4 days ago | parent [-]

I am fine with the subsequent example, too. If you read up about slices, then that's how they are defined and how they work. I am not judging, I am just using the language as it is presented to me.

For anyone interested, this article explains the fundamentals very well, imo: https://go.dev/blog/slices-intro

▲

terminalbraid 4 days ago | parent [-]

Then you seem to be fine with inconsistent ownership and a behavioral dependence on the underlying data rather than the structure.

You really don't see why people would point a definition that changes underneath you out as a bad definition? They're not arguing the documentation is wrong.

▲

a day ago | parent | next [-]

[deleted]

▲

rustandmore a day ago | parent | prev | next [-]

Ownership is perfectly consistent.

`append` always returns a new slice value

`func append(slice []Type, elems ...Type) []Type`

The only correct way to use append is something like `sl = append(sl, 1, 2, 3)`

`sl` is now a new slice value, as `append` always returns a new slice value. You must now pass the new slice value back to the user, and the user must use the new slice value. The user must not use the old slice value.

It's trivial to fix the "bug" in the article, once you actually understand what a slice value is: https://go.dev/play/p/JRMV_IuXcZ6

A slice is not the underlying array, and the underlying array is not the slice. A slice is just a box with 3 numbers.

▲

assbuttbuttass 4 days ago | parent | prev [-]

The definition is perfectly consistent. append is in-place if there's enough capacity (and the programmer can check this directly with cap() if they want), and otherwise it allocates a new backing array.

	▲	terminalbraid 4 days ago \| parent [-]
		Yes, it's consistent and complicated and non-intuitive. "Consistent" is necessary but not sufficient for "good".