I've tried this example, related to the collections example in the
proposal.
package main
type Iterator[T any] interface{
Next() (T, bool)
}
func Contains[T comparable](c Iterator[T], value T) bool {
for {
v, ok := c.Next()
if ok {
if v == value {
return true
}
} else {
return false
}
}
}
type SliceIterator[T any] struct{
Slice []T
}
func (l *SliceIterator[T]) Next() (value T, ok bool) {
ok = len(l.Slice) > 0
if ok {
value = l.Slice[0]
l.Slice = l.Slice[1:]
}
return
}
func ContainsInt(l *SliceIterator[int], i int) bool {
return Contains(l, i) // (1)
}
func Contains2[T comparable](value T, c Iterator[T]) bool {
return Contains(c, value)
}
func ContainsInt2(l *SliceIterator[int], i int) bool {
return Contains2(i, l) // (2)
}
func main() {}
This does not compile, with errors on lines (1) and (2):
t.go:34:18: type *SliceIterator[int] of l does not match Iterator[T] (cannot
infer T)
t.go:42:22: type *SliceIterator[int] of l does not match inferred type
Iterator[int] for Iterator[T]
I think this matches the described algorithm. But it's really
unfortunate, given that we have a trivial unification in one of the
parameters.
Can this be fixed? Perhaps the challenge is that there are several
factors that conspire to make the precise choice of a type parameter
significant: lack of erasure, associated zero value with any type
parameter, reflection. Two matching instantiations with difference
interface types may have different behaviors. This may be the reason
why the present design is so picky about type inference.
--
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/871r3s2q84.fsf%40mid.deneb.enyo.de.
