That's interesting; thanks for the heads up.
My initial reaction is that this perhaps feels a bit "clever", but perhaps
this feeling will go away in time.
Constraint type inference is useful when a function wants to have a type
> name for an element of some other type parameter, or when a function wants
> to apply a constraint to a type that is based on some other type parameter.
I found this initial sentence describing the motivation behind the feature
a bit abstract and hence hard to understand:
Perhaps a tiny example might help at that point to orient the reader in the
right direction?
Constraint type inference can only infer types if some type parameter has
> a constraint that has a type list with exactly one type in it.
When I first read the above, my first thought was: but it's not very useful
then because when would you have a type list with only one type in?
Of course, it becomes clear later that you'd define this kind of constraint
precisely to use this feature, but perhaps the phrasing could be changed a
little to make that more obvious?
Overall, I like the fact that this feature uses the existing semantics of
type lists and only extends the type-inference algorithm.
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.
So, for example:
var f = DoubleDefined[MySlice, _]
would be valid. f would be a function value of type func(MySlice) MySlice.
cheers,
rog.
On Thu, 13 Aug 2020 at 03:31, Ian Lance Taylor <i...@golang.org> wrote:
> I just added a new section to the generics design draft describing
> constraint type inference. This is a generalization and
> simplification of the earlier pointer method approach, which has now
> been removed. I would be happy to hear any comments. Thanks.
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>
> 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/CAOyqgcX6AcGUt4e6JTMrxXkAtMRq%2Bo6zSVnjqchEroheYBP%2BBw%40mail.gmail.com
> .
>
--
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/CAJhgaciL%3D0p3rwMOmXW3oxNFhKVWFa6bT6-SsBi-E5iaeFxYqQ%40mail.gmail.com.
