Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
go/types: inconsistent handling of untyped expressions #13061
Currently if you type check this code with go/types:
My expectation was that the
It also seems inconsistent with conversions of already typed expressions, where they're not rewritten.
However, I notice api_test.go has a bunch of tests that seem to explicitly test for this behavior, so it seems intentional?
@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
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:
I'm actually rather surprised to find out the above is not valid Go (whereas
The reason for the inconsistent behavior is that
Removing the special case for
According to the comment, it's important to record the
There may be a solution, still. Leaving open for now.