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.
On Fri, Aug 14, 2020 at 5:40 AM roger peppe <rogpe...@gmail.com> wrote:
>
>
> On Thu, 13 Aug 2020 at 23:30, Ian Lance Taylor <i...@golang.org> wrote:
>
>> On Thu, Aug 13, 2020 at 3:09 PM roger peppe <rogpe...@gmail.com> wrote:
>>
>>
>> >
>>
>>
>> > I do feel that the "all or nothing" nature of type parameter lists (if
>> you specify one type parameter, you must explicitly specify all of the
>> others too, even if they could otherwise be inferred) is likely to get in
>> the way here. I'd like to see a way to specify some type parameters and not
>> others, so that constraint type inference can work even when, for example,
>> there's a generic return type parameter that can't be inferred from the
>> arguments. We could potentially use an underscore for that.
>>
>>
>>
>>
>>
>> If I understand you correctly, we changed that when we added the
>>
>>
>> constraint type inference section. See the updated
>>
>>
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference
>>
>>
>> section.
>>
>
> Ah, that's useful and interesting, thanks. I suspect that being able to
> selectively omit type parameters could be useful though - for when there's
> no obvious ordering to the parameters and you want to infer some of the
> earlier types in the list while specifying some later ones. Maybe in
> practice it'll always be possible to use an explicit type conversion in a
> value parameter to do this though, especially if Steven
> Blenkinsop's ordering suggestions are followed (perhaps that could be a `go
> vet` checki).
>
> cheers,
> rog.
>
>>
>>
>> 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/CAJhgacjPfoUp%2Bkhb4csuF%2Bz%3DTEWchZuSri94yTP4%2BtRvtnK5Ng%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAJhgacjPfoUp%2Bkhb4csuF%2Bz%3DTEWchZuSri94yTP4%2BtRvtnK5Ng%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
>
--
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/CANjmGJvgk%2BRgAgUwfgDutCGNiqZHzH0KCCh2aZ0Gp_UeG%2BHnjA%40mail.gmail.com.
