Which is why I believe this can happen with existing interfaces and compiler magic. (along with my other proposal regarding carrying the concrete type in slices).
You can do operator overloading and type conversion with interfaces. (although not a big fan of operator overloading…) Method overloading requires no new keywords. Generic collections can probably be implemented with interfaces (Iterable for the range keyword, Equality, Comparable) and some compiler magic. No new keywords or syntax needed. > On Sep 9, 2018, at 7:50 AM, Eric S. Raymond <e...@thyrsus.com> wrote: > > Ian Lance Taylor <i...@golang.org>: >> As I've said before, I would very much like to avoid adding many >> different names to the language. > > I've been staying out of the forward-looking language-design discussions so > far, > and intend to keep pretty quiet on that front until I feel my grasp on > idomatic Go as she is now spoke is more complete. > > This, however, is not a Go-specific issue. Ian is absolutely right to be > conservative here on general principle. Go as it stands now is an admirably > compact language; its keyword inventory is small, its syntax is simple, and > the whole fits relatively easily into a Mark I brain. > > It is easy, in a zealous reach to extend the expressiveness of a > language, to undervalue compactness until you have lost it. At which > point you find yourself in a maze of twisty little language > constructs, all different, and realize that the friction cost of using > the language has zoomed, subtly vitiating the gain from any individual > feature. > > I'm not here to say I think every single decision in the Go design is > perfect. But I think the minimalist style of the language was - and > is - a very wise choice. Like Ian, I will cast a very skeptical eye > on any extension proposals that seem to add more *stuff* - more > keywords, more overloading of existing constructs (and underneath > them, more semantic elaboration) without a very high gain in > expressiveness per *each individual* increment of complexity. > > I wasn't planning to name any names when I began this rant, and maybe > I still shouldn't, but...now I think it must be said in order to > underline the general point. Those of you advocating generics by > contract, in particular, need to think hard about what they would do > to compactness. > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be your > own. > > > -- > 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. -- 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.
