And unsafe.Sizeof etc.

Yes, this meets every use case that has frustrated me in code.

Change https://golang.org/cl/179184 mentions this issue: go/types: change cap, len to return untyped int if result is constant (experiment)

It turns out that per the spec, unsafe.Sizeof (and its siblings unsafe.Offsetof, unsafe.Alignof) return a uintptr rather than an int, which makes it impossible to change these in a backward-compatible way: even though they always return a constant, if that were an untyped int it would not default to uintptr. A place where this is causing problems is for instance in file https://golang.org/src/cmd/vendor/golang.org/x/sys/unix/syscall_darwin.go on line 353 where n is supposed to be of type uintptr.

But we should be able to do it for len and cap without problems - and indeed there aren't any in the stdlib as a type-checking it via a modified type checker shows (apply CL 179184 and run go test go/types which will run the go/types over all packages of the std lib, among other tests).

As an aside, changing len and cap as described is in the spirit of the built-ins complex, real and imag which also return an untyped result if the argument(s) are untyped.

Rather than make cap and len only evaluate to untyped when their arguments are constant, why not just always make them untyped?

Non-constant comparisons are still untyped bool when their operands are typed.

Edit: To answer my own question, because if we allowed var x byte = len(s) where s is a non-constant string, then we'd have to define what to do for strings over 255 bytes long. Would we silently truncate? Would we panic?

It turns out that per the spec, unsafe.Sizeof (and its siblings unsafe.Offsetof, unsafe.Alignof) return a uintptr rather than an int, which makes it impossible to change these in a backward-compatible way: even though they always return a constant, if that were an untyped int it would not default to uintptr.

We could make them evaluate to "untyped uintptr" lol.

@mdempsky As you noted, the problem with making len always untyped is the size of the result. For booleans (and also strings) the size is known, no matter what kind of boolean (or string).

Will this change allow const X = len("Go") + 2i and complex(len("Go"), 2)?

yes

I am not sure the costs here are worth the benefit. Today there is a simple rule: len(x) has type int. Changing the type to depend on what x is will interact in non-orthogonal ways with various code changes. For example, under the proposed semantics, this code compiles:

const x string = "hello"
func f(uintptr)
...
f(len(x))

but suppose then someone comes along and wants to be able to modify x for testing or something like that, so they s/const/var/. That's usually fairly safe, but now the f(len(x)) call fails to type-check, and it will be mysterious why it ever worked.

This change seems like it might add more rough edges than it removes.

Agreeing with @rsc here. While this seems like an easy win at first glance, it's not clear that the corner cases are worth the extra complexity. I am retracting this proposal.