CC @griesemer

Given the example above, what should be inferred for T for the call Add(1, 2.0) ? int, float32, and float64 would all be valid answers. And even if we ignore float32 (it's not a default type), we still have two valid choices.

We can come up with rules, but it smells like an unnecessary complication. A minor change to a constant value, possibly defined somewhere else, may suddenly change an inferred type.

If I write 1 + 2.0 it gets typed float64 so I would expect the same type for T.

I don't know if this diagram will help but:

On one hand we have 1 : untyped integer + 2.0 : untyped floating point -> (1 + 2.0) : untyped floating point -> (1 + 2.0) : float64

On the other we have Add[T](1 : untyped integer, 2.0 : untyped floating point) -> Add[T](1 : int, 2.0 : float64) -> error.

I'm asking for Add[T](1 : untyped integer, 2.0 : untyped floating point) -> Add[T : untyped floating point](1, 2.0) -> Add[T : float64](1, 2.0). That is, instead of immediately taking the default types retain the untyped type a little longer so that the default type that works for all instances of the parameter is chosen.

int, float32, and float64 would all be valid answers

I don't follow why float32 would be a contender.

If I write 1 + 2.0 it gets typed float64 so I would expect the same type for T.

Agreed. Assuming int and float64 for Add(1, 1.2) made sense before generics when Add was:

func Add(x, y interface{}) {...}

because each value could be evaluated in isolation. Now, with type parameters, with the generic Add, the arguments' types are linked, so one must affect the other. It's the same in 1 + 1.2, where the spec requires the operands to have the same type, which is equivalent to the generic function Add. See how Haskell handles apparent mismatched types from different literal kinds in its type checking.

I thought a bit more about this and I retract my earlier comment.

I believe @jimmyfrasche is correct that if two arguments of the same type parameter type get assigned different untyped values, an analogue rule should apply as for a constant operation between these two untyped values.

Specifically, the proposal is:

If numeric untyped arguments of different kinds are passed to function parameters of the same (as of yet uninferred) type parameter type, the (combined) argument's kind is the one that appears later in this list: integer, rune, floating-point, complex. The inferred type for the type parameter is the respective default type for that kind.

Example:

func g[P any](...P) P { var x P; return x }

func _() {
	var (
		_ int        = g(1, 2)
		_ rune       = g(1, 'a')
		_ float64    = g(1, 'a', 2.3)
		_ float64    = g('a', 2.3)
		_ complex128 = g(2.3, 'a', 1i)
	)
	g(true, 'a' /* ERROR "mismatched types untyped bool and untyped rune (cannot infer P)" */)
	g(1, "foo" /* ERROR "mismatched types untyped int and untyped string (cannot infer P)" */)
	g(1, 2.3, "bar" /* ERROR "mismatched types untyped float and untyped string (cannot infer P)" */)
}

This is unambiguous, fits nicely with the existing rules for constants (as @jimmyfrasche has pointed out before) and thus feels "natural" for Go. It is fully backward-compatible: existing code will continue to run, and some code that wasn't accepted before is now accepted. It removes possibly annoying type inference errors. As an aside, it is about as complex to implement as what we do now.

I believe we should do this.

Change https://go.dev/cl/492835 mentions this issue: go/types, types2: infer minimum default type for untyped arguments

I think cmp.Min, as proposed in #59488, is an argument in favor of this. When build tags are used to give constants different values for different configurations, it becomes reasonable to write cmp.Min(a, b) for untyped constants a and b. We would expect that to work if a and b are arbitrary numeric constants. We would not expected it to fail for const a = 0 and const b = 1.5. Making type inference work for untyped constants is similar to how we can already write a + b for this example.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

Change https://go.dev/cl/495955 mentions this issue: cmd/compile: more lenient type inference for untyped arguments

Change https://go.dev/cl/496035 mentions this issue: cmd/compile: permanently enable more lenient type inference for untyped arguments

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

This has been implemented and submitted. Leaving this open to track documentation in the spec.

Change https://go.dev/cl/499282 mentions this issue: doc/go1.21: document type inference changes

Change https://go.dev/cl/499997 mentions this issue: go/types, types2: remove version check for more lenient constant handling in inference

This is now described in the new section on type inference in the spec, per CL 503920.
Closing.