I also like this proposal, and have a related proposal with a somewhat different syntax that is even simpler and is essentially identical to existing Go code, just with “Generic Native Types” (GNT). Here’s a couple of side-by-side comparisons:
///////////////////
// Min
Michal’s:
func Min(x, y type T ord) T {
if x < y {
return x
}
return y
}
GNT:
func Min(x, y number) type(x) {
…
}
///////////////////
// SyncMap
Michal’s:
type SyncMap(type K eq, type V) struct {
mu sync.Mutex
m map[K]V
}
func (sm *SyncMap(type K eq, type V)) Store(key K, value V) {
sm.mu.Lock()
sm.m[key] = value
sm.mu.Unlock()
}
GNT:
type SyncMap struct interface {
mu sync.RWMutex
m map // a generic map
}
func (m *SyncMap) Store(k key(m.Map), v elem(m.Map)) {
…
}
A struct interface is like an interface, specialized for struct -- any struct with the specified fields gets the generic methods, instantiated for the concrete type, e.g.,:
// MySyncMap instantiates the SyncMap struct interface...
type MySyncMap struct {
mu sync.RWMutex
m map[string]string
}
Here’s a significantly improved version of the proposal originally posted a few weeks ago:
https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d This proposal also specifies a complete set of *fixed* “contracts” that are isomorphic to the existing native types, so it might appeal to people who prefer more explicit semantics for the generic args, compared to more generic generics. Cheers,
- Randy
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/199bad6c-ed62-44a6-960b-86503242537a%40googlegroups.com.