[Apologies to Dave Cheney, timely pushback for David Collier-Brown] David, I disagree and suggest your remark is not well considered. Three replies, one per sentence.
*"Right now, this looks like the third draft of an academic project."* Not to me. This reads like years of thought and discussion among qualified researchers and skilled implementers. Not to boast unduly, but if you look at the history of Ian, Robert, and Russ, you'll see intimate responsibility not only in Go but in Gnu C/C++, Modula, and more. What I see in the proposal is informed wisdom. This is engineering so there is always a better way, but this may be the best that can be seen before implementation and experience. *"It suffers badly by comparison to make(), the existing mechanism."* Yes, inherently so. The existing mechanism uses magic in parsing and implementation—details known in the compiler but not exposed in the Go language generally, to make things as easy as possible. It is nice. But from before the launch of Go users asked "how can I do such things generally, in my code, and not by extending the language or the compiler." The answer was "use interfaces now and we'll think about generics later." Later is now and indeed exposing aspects of behind the scenes compiler magic is more complicated, that's inherent. The decision to be made is how powerful vs how complicated. "Can we see some more alternatives, please?" They are legion. Existing generics approaches in various languages are more than ideas, they are living examples of design, ecosystem, and behavior. Several proposals have been offered by the Go team and collaborators here. The Go 2 design site lists many specific comments and alternatives. Extensive thoughts have been shared, with *responsa sunt, novi in via*. Not a personal attack. Trying to inform these statements and encourage review and consideration. Michael On Thu, Sep 20, 2018 at 5:04 AM David Collier-Brown <dav...@spamcop.net> wrote: > Right now, this looks like the third draft of an academic project. It > suffers badly by comparison to make(), the existing mechanism. > > Can we see some more alternatives, please? > > --dave > > -- > 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. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.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. For more options, visit https://groups.google.com/d/optout.
