-----Original Message-----
>From: Randall O'Reilly <rcoreil...@gmail.com>
>Sent: Jun 5, 2019 1:58 PM
>To: Ian Lance Taylor <i...@golang.org>
>Cc: Michal Strba <faiface2...@gmail.com>, golang-nuts
><golang-nuts@googlegroups.com>
>Subject: Re: [go-nuts] Go 2 generics counterproposal: giving up restricting
>types
>
>On Jun 5, 2019, at 12:03 PM, Ian Lance Taylor <i...@golang.org> wrote:
>>
>> On Wed, Jun 5, 2019 at 10:47 AM Randall O'Reilly <rcoreil...@gmail.com>
>> wrote:
>>>
>>> It’s great to see that so many people share my considerable enthusiasm for
>>> this proposal! Seriously, nobody is willing to take a look and provide any
>>> feedback?
>>>
>>> - Randy
>>>
>>>> On Jun 3, 2019, at 2:53 AM, Randall O'Reilly <rcoreil...@gmail.com> wrote:
>>>>
>>>> I wrote up a coherent proposal based on the core of the idea below, and
>>>> added it to the feedback wiki:
>>>>
>>>> https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d
>>>>
>>>> Overall I think it seems quite promising as perhaps the most “Go” version
>>>> of generics possible, which solves the major use-cases, while retaining
>>>> essentially the same existing syntax and just adding a few additional
>>>> keywords. I can’t see any major limitations other than those intrinsic to
>>>> the idea itself (e.g., you can’t define a Min function that works across
>>>> any type whatsoever), and I don’t think it introduces any violations of
>>>> existing static type safety. Curious to hear what others think! Cheers,
>>
>>
>> I don't understand how to use this proposal to write a type-safe
>> concurrent hash map. I think that is one of the key features that a
>> generics implementation needs to support.
>
>you can do any valid map operation on the generic type “map”, so at a minimum
>it seems like you could just add an appropriate mutex around each of the
>different operations, using a struct interface:
>
>package safemap
>
>type M struct interface {
> Map map
> Mu sync.RWMutex
>}
>
>func (m *M) Set(k key(m), v elem(m)) {
> m.Mu.Lock()
> if m.Map == nil {
> m.Map = make(m.Map)
> }
> m.Map[k] = v
> m.Mu.Unlock()
>}
>
>…
>
>any concrete map that shares that struct interface type signature
>automatically gets the associated methods:
>
>import safemap
>
>// MySafeMap implements the safemap.M struct interface
>type MySafeMap struct {
> Map map[string]string
> Mu sync.RWMutex
>}
>
>func MyFunc() {
> m := MySafeMap{}
> m.Set(“mykey”, “myval”) // at this point the Set method knows the concrete
> type of “m”, can compile Set
>}
>
>> As a less important issue, relying on a general construct like
>> "number" is problematic in Go. There are many different ways to slice
>> up Go's types. "number" is just one of them. There is also integer,
>> signed integer, unsigned integer, comparable, ordered, float, complex.
>> One can even think of addable (includes string) and indexable and
>> sliceable.
>>
>> Ian
>
>The proposal already does include some of those number subtypes (I did leave
>out complex, for simplicity..). There is probably some optimal 80/20 choice
>to decide exactly which generic number categories to include. For example,
>ordered could just be identical to number (i.e., all the different ints,
>floats, but excluding complex which is not really a number in the same sense —
>it is more like a vector). You could add comparable to include complex+number
>but it might be simpler to just say that if you’re writing a generic function
>that operates on complex numbers, you have to use the “complex” generic to
>subsume 64 and 128 variants, and otherwise it is excluded from the “number”
>category and probably few people will notice or complain.. Likewise, maybe
>you don’t need generic “integer” in addition to both “signed” and “unsigned”
>(I’ll update my proposal to use “signed” instead of “integer” as that is more
>specific), but maybe the one extra keyword is worth it. Anyway it seems like
>these details could definitely be worked out if the overall idea holds water.
>
>I wasn’t really sure to do about string — might be useful to see how far you
>can get just treating it as a byte array from the generic perspective —
>otherwise it already stands alone in a type class by itself, so it doesn’t
>really need a generic version.
>
>Adhering to the minimalist approach, I’m pretty sure you could most of what
>you want while avoiding things like addable, indexable and sliceable, and just
>using map, slice, array and their existing operators in a generic way.
>
>
>--
>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/DA59DC24-5C4A-4712-9CB2-B155A7C459DD%40gmail.com.
>For more options, visit https://groups.google.com/d/optout.
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/1039154797.5929.1559762231749%40wamui-megara.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.
