CC @griesemer

The error message is correct, but perhaps we can produce a better message in this case. It seems that we are reporting an argument type mismatch before we report a constraint failure.

@ianlancetaylor I can't agree that the error message is correct. It made me little bit crazy and burned about half an hour of my work time to understand what is exactly wrong and how to fix it. Just imagine little bit more difficult code. And try to explain how I should understand the real reason of issue with code having such miss-pointing error message.

For generic functions the type constraints have to be performed before or in additional to check of argument type mismatch. Other way there is no way to produce the correct error message.

@Dmitriy-Kulagin In general, we cannot check constraints before we have all type arguments (because constraints may be parameterized with type parameters). This order is explicitly specified in the spec:

Instantiation proceeds in two steps:

1. Each type argument is substituted for its corresponding type parameter in the generic declaration. This substitution happens across the entire function or type declaration, including the type parameter list itself and any types in that list.

2. After substitution, each type argument must satisfy the constraint (instantiated, if necessary) of the corresponding type parameter. Otherwise instantiation fails.

That is, step 1 happens first. For that to happen, we first need to determine all type arguments.

The error happens when we determine the type arguments, and the error is correct. It's also fairly easy to read:

type func(value string) bool of f does not match inferred type func(value float64) bool for func(value T) bool

The inferred type for func(value T) bool is explicitly given as type func(value float64) bool. It's easy to see that this type was inferred from the 1st argument to checkValue, that argument has type float64. And clearly, the two function types don't match.

You are (implicitly) saying that the error should be something like:

cannot use v (of type float64) as type argument, v doesn't satisfy constraint

This may be easier to understand for you in this case, but it would require special-case handling (need to check if the constraints are parameterized). This may be possible but will slow down the usual (correct) case. Going forward, as we make type inference more powerful, it will become more and more difficult (type parameters may also appear on the argument side) for little benefit. It may also introduce subtle bugs because we are deviating from the spec (which is directly guided by what the type theory behind generics says is correct).

Most importantly, the code is incorrect either way. From the current message it's easy to see that the float64 value parameter doesn't match the string value parameter. So make that string and things will work.

Closing as working as intended.