-----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/1126883664.6359.1559765934704%40wamui-megara.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.
