@mdempsky It is definitively intentional - untyped constants are given their "inferred" type so that a backend - which needs to materialize the constants - knows of what type and size a constant is.

My guess would have been - for the example above - that the types would be int, untyped int, *nil, and untyped nil, but I need to look into the logic again.

I suspect the reason for the inconsistency is that nil is not considered a constant and thus perhaps is handled in a different code path.

I'd think the backend could determine the needed type and size for materializing the constants some other way (e.g., looking at the type of the variable they're being assigned to)? But at least if 0 in int(0) and nil in (*int)(nil) became "untyped int" and "untyped nil", respectively, like you suggest, that would help my immediate problem of wanting to identify unnecessary conversions.

I took a stab at this, but discovered the trivial fix (just don't propagate types to explicit conversion arguments) causes a regression on this test case in test/fixedbugs/bug193.go, because it no longer detects the expected errors:

func main() {
        s := uint(10)
        ss := 1 << s
        y1 := float64(ss)
        y2 := float64(1 << s) // ERROR "shift"
        y3 := string(1 << s)  // ERROR "shift"
        _, _, _, _, _ = s, ss, y1, y2, y3
}

I'm actually rather surprised to find out the above is not valid Go (whereas float64(1 << uint(10)) is valid), but it seems to be in the spec:

If the left operand of a non-constant shift expression is an untyped constant, it is first converted to the type it would assume if the shift expression were replaced by its left operand alone.

Hrm.

@mdempsky yes, shifts are tricky business . i'll take care of this (let me know if this is blocking you)

Nope, not blocking me. I was just interested in better understanding the problem.

Investigate and decide what to do.

Ping Robert. You'd labeled this Go 1.9.

I think this can be safely bumped to 1.10. Nothing changed during 1.9 with respect to this issue.

The reason for the inconsistent behavior is that nil is indeed handled specially, see go/types/expr.go, Checker.convertUntyped function, at the end:

case *Pointer, *Signature, *Slice, *Map, *Chan:
	if !x.isNil() {
		goto Error
	}
	// keep nil untyped - see comment for interfaces, above
	target = Typ[UntypedNil]

Removing the special case for nil (deleting the line target = Typ[UntypedNil]) will produce consistent output where all untyped values in this case get registered with their "target" type; i.e., the untyped nil we see would become *int as well.

According to the comment, it's important to record the untyped nil here for tools like vet. We could do the same for non-nil values but as @mdempsky noticed, this causes problems with shifts.

There may be a solution, still. Leaving open for now.

It does seem reasonable to record the untyped type for values that are explicitly converted. So we should definitively fix this.

CL 283872 is addressing this partly for types2 (in dev.typeparams branch): with this CL, untyped nils consistently report the type untyped nil (even in conversions). This makes the untyped nil behavior consistent across all operations involving nil.

For any other untyped operand we do report the "context type" though, which is different from the behavior for nil. This is necessary (at the moment) to make shifts behave correctly, e.g. int(1.0 << s) is valid because the type of 1.0 is int due to the conversion.

It may make sense to always report the context type for any untyped value (even untyped nils).

cc: @mdempsky

Change https://golang.org/cl/284052 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: consistently report nil type as "untyped nil"

Change https://golang.org/cl/289715 mentions this issue: [dev.regabi] go/types: consistently report nil type as "untyped nil"