The all-or-none aspect would be sidestepped if it were allowed to define
"partial generics":
func A (T1, T2) (...){....}
func B(T)(...){ A(T,int)(...){...} }
Allowing B to exist just means running the whole generic thing iteratively
until no resolution is changed. If the fixed point still has generic types
then the compilation is a failure, otherwise, a success.
Seems useful to me. A generic balanced tree infrastructure could be
"meta-instantiated" as a LLRB instance that still allows generic leaf types.
On Thu, Aug 13, 2020 at 3:09 PM roger peppe <rogpe...@gmail.com> wrote:
> 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
> <https://groups.google.com/d/msgid/golang-nuts/CAJhgaciL%3D0p3rwMOmXW3oxNFhKVWFa6bT6-SsBi-E5iaeFxYqQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@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/CALoEmQxJM0%2Bi9ri9FMV0zQ2L6R9zvH5eHHbXEQYci5XW6dzwFg%40mail.gmail.com.
