Earlier quoted context omitted.
It’s the C tradition, continued.
Go would have undoubtedly been called D had the name not already been taken.
It is not like Go wasn't already taken.
Go(lang): Robust generic functions on slices
81–85 of 85 posts
Re: Go(lang): Robust generic functions on slices
#82Re: Go(lang): Robust generic functions on slices
#83From the article:
> Several new functions (Insert, Replace, Delete, etc.) modify the slice. To understand how they work, and how to properly use them, we need to examine the underlying structure of slices. [My emphasis]
What this is telling us, although perhaps the author doesn't appreciate, is that this isn't an abstraction. If it was an abstraction we don't need to "examine the underlying structure of slices" in order to properly use them, we can just treat them as opaque. But in Go that's not an option, intimate knowledge of the inner workings is crucial to correct programming in Go.
And that's not necessarily a problem for its main authors, who have anyway got such an understanding, but it should have given pause to somebody who thought about how you can effectively teach others to use this language. For Go in particular that's a huge problem because it's intended as a language for software engineering and for that purpose you do want to rely heavily on abstraction.
Re: Go(lang): Robust generic functions on slices
#84I feel like I’m taking crazy pills. How are these APIs even remotely defensible? slices.Sort(s) // fine slices.Compact(s) // broken s = slices.Compact(s) // fine s := slices.Compact(s) // broken (!!!) slices.Delete(s, …) // broken s = slices.Delete(s, …) // fine How is one intended to remember which functions require overwriting (due to invalidating) their input and which don’t? Why does the language make it so easy…
> slices.Compact(s) // broken
I don't quite get what you mean by 'broken' here. You know that the length of a slice can't be altered by passing it to a function. So clearly s will still contain the same number of elements as it did before the call to Compact. Similarly for Delete.
You can ignore the return value of the function and that might introduce a bug in your code. But that's something that could happen with all kinds of functions.