On Mon, Aug 24, 2020 at 4:34 PM Patrick Smith <[email protected]> wrote:
>
> I may be missing something, but it seems to me that one point in the draft's 
> discussion of type inference could usefully be clarified 
> (https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference).
>
> The term "type parameter" there should be restricted to the type parameters 
> in the specific use of a generic type or function for which we are trying to 
> infer type arguments. For example (https://go2goplay.golang.org/p/pWis3rlJElu)
>
> func Min[type T interface{ type int, uint }](a, b T) T {
>
> if b < a {
>
> return b
>
> }
> return a
>
> }
>
> func Min3[type U interface{ type int }](a, b, c U) U {
>
> return Min(a, Min(b, c))
>
> }
>
> func BadMin3[type V interface{ type int, uint, string }](a, b, c V) V {
>
> return Min(a, Min(b, c))
>
> }
>
> Here, U and V are type parameters, but when inferring type arguments for the 
> calls to Min, we must consider U and V as fixed types, not subject to type 
> unification. This seems needed in order for the compiler to reject BadMin3.

Thanks.  That seems fairly clear to me, but I'm probably too close to
the problem.  Any suggestions for exactly where we should add a
sentence, and what that sentence should be?  Thanks.

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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVOWb_snspcZ_mu8sBPSKV9jUHMp%2BGxVO1Q8E0PxQgcZQ%40mail.gmail.com.

Reply via email to