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.
