Ian, have you had the time to evaluate the improvements to my proposal (the original one in this thread)? I'd love to hear if it has some more significat shortcomings and know what to think about. Or, if it has no perspective, I'd love to hear why.
I know you're busy, so responding with "I haven't had the time yet" is completely understandable. Thanks On Wed, Jun 5, 2019, 22:18 Robert Engels <reng...@ix.netcom.com> wrote: > > > > > > > -----Original Message----- > >From: Randall O'Reilly <rcoreil...@gmail.com> > >Sent: Jun 5, 2019 2:33 PM > >To: Robert Engels <reng...@ix.netcom.com> > >Cc: Ian Lance Taylor <i...@golang.org>, Michal Strba < > faiface2...@gmail.com>, golang-nuts <golang-nuts@googlegroups.com> > >Subject: Re: [go-nuts] Go 2 generics counterproposal: giving up > restricting types > > > >That is a good point of clarification about the specific limitation of > this proposal: it specifically reifies the existing Go type system and does > NOT enable the generic-ification of arbitrary novel types. If you can > build a specialized type out of generic versions of existing Go types, then > you’re good, but if you need something entirely different, then this won’t > do it. The key question is whether having a really simple and tractable > “native types” version of generics solves enough problems, while avoiding > the challenges of going “fully generic”, to hit that “Go” minimalism sweet > spot.. > > > >- Randy > > > >> On Jun 5, 2019, at 1:17 PM, Robert Engels <reng...@ix.netcom.com> > wrote: > >> > >> That is not sufficient. You can't require the usage of the built-in > map, as specialized maps may have a completely different structure (special > hash tables when the keys are ints, or more commonly special CAS techniques > for highly concurrent lock-free maps). > > > >-- > >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. > >To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/735428D9-5630-4F56-88AD-0F8E9E8CC473%40gmail.com > . > >For more options, visit https://groups.google.com/d/optout. > > Even more common data structures like linked maps, tree maps/sets wouldn't > be possible. I think custom data structures are the prime usage for > generics - which is why I suggested that rather than doing generics, you > could do something like this: > > map:=make(map[String]String,"ordered,concurrent") > > which would use different implementations as decided by the Go platform > (with maybe some way of registering additional ones via C, etc.) > > It keeps the simplicity of Go, using the existing syntax, but allows > custom data structures (although not written in Go - maybe?) > > I think data structures are 95% of the use case of generics, but that is > just my opinion (although earlier Java based studies I referred to seemed > to support the claim). > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAO6k0uu2%3DGriMy7gAYP2UMrApNg%2BN_WNR0_g5w0sRvvK7FvRqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
