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.
