Michael, Considering all improvements you've made to the original, is the current version of your proposal clear to all following this thread ?
On Wednesday, June 5, 2019 at 6:03:12 PM UTC-4, Michal Strba wrote: > > 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 <ren...@ix.netcom.com > <javascript:>> wrote: > >> >> >> >> >> >> >> -----Original Message----- >> >From: Randall O'Reilly <rcore...@gmail.com <javascript:>> >> >Sent: Jun 5, 2019 2:33 PM >> >To: Robert Engels <ren...@ix.netcom.com <javascript:>> >> >Cc: Ian Lance Taylor <ia...@golang.org <javascript:>>, Michal Strba < >> faifa...@gmail.com <javascript:>>, golang-nuts <golan...@googlegroups.com >> <javascript:>> >> >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 <ren...@ix.netcom.com >> <javascript:>> 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 golan...@googlegroups.com <javascript:>. >> >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/435b5a90-05ea-4d71-bfc7-47ec3824d5d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
