On Tue, Sep 8, 2020 at 5:47 PM Steven Blenkinsop <steven...@gmail.com> wrote:
>
> Reading over the pointer method example, I noticed that a derived type cannot
> be inferred in a nested call while leaving method constraints intact:
>
> type DerivedTypeConstraint[T any] interface {
> type *T
> Method()
> }
>
> func Foo[T any, PT DerivedTypeConstraint[T]](_ T) {}
>
> func Bar[T any, PT DerivedTypeConstraint[T]](t T) {
> Foo(t) // Error: *T has no methods
> }
>
> type S struct{}
>
> func (S) Method() {}
>
> func main() {
> Bar(S{}) // This is fine, PT gets inferred as *S, which implements Method
> }
>
>
> https://go2goplay.golang.org/p/9GMdhTbcMDs
>
> Obviously, you can work around this by passing PT explicitly rather than
> letting *T be inferred. It's just unfortunate that, even though *T must have
> any methods in the constraint on PT (any other type with the same underlying
> type would have no methods), the compiler isn't, and most likely shouldn't
> be, smart enough to figure that out. I'm not sure how to solve this, but I
> think it makes the design feel a little less polished.
I think that it's really crucial for type inference rules to be as
simple and clear as possible. There must never be any confusion as to
what an inferred type might be. In complicated cases, it's fine to
explicitly list the type arguments. In fact, it's more than fine:
it's desirable.
Ian
--
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/CAOyqgcWrPLkq61GZBYQ%3Dt5zhnd%3DY%3DbtBhSEBT9XNmBnpfvVY3g%40mail.gmail.com.
