[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.

Reply via email to