zlacker

>>ustad+(OP)
> Probably [hello NIGHTMARE !]. Who wants that? Nobody wants that.

I don't really care if you want that. Everyone should know that that's just the way slices work. Nothing more nothing less.

I really don't give a damn about that, i just know how slices behave, because I learned the language. That's what you should do when you are programming with it (professionally)

>>813ac4+Zg
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".

>>termin+3i
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

>>813ac4+Di
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.

>>termin+hj
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.

>>assbut+vl
Yes, it's consistent and complicated and non-intuitive.

"Consistent" is necessary but not sufficient for "good".