Should const-evaluation be dynamically-typed or statically-typed? (And with what types?)

[pnkfelix]

Currently our handling of types in const-evaluation is pretty ad-hoc.

See for example: rust-lang/rust#23833 or more generally several on the list at rust-lang/rust#23897

The const-evaluator often tries to act like it can figure out an expected type from the context and pass it in, but this is not always possible in general.

And in any case, it may make more sense to have the const-evaluated values carry around the actual computed types. But then this leads to issues like: Should the computed types be so strict as to be "this is the value -3 of type i8"? Or would it be better to be more flexible and have the computed type just be "this is the value -3 of type signed integer, so that it could be used with any signed integer type that can hold that value?

[pnkfelix]

(I consider rust-lang/rust#15270 to be a specific instance of this, so I am not planning to clone that issue.)

[pnkfelix]

potentially related recent PR attempt: rust-lang/rust#18538

My first thought here would be that constant evaluation should never differ from runtime evaluation in this regard, that is, a constant expression should be accepted by the type checker iff its runtime equivalent is.

[pnkfelix]

"iff" may be a bit stronger than I would like.

There may be expressions we want to accept at runtime because they do interesting things that have to do with the target architecture -- but those same expressions are likely to be very difficult to make any sense of at compile time. I'm thinking in particular of integer-to-pointer casts, where the original integer was computed solely from literal inputs, and not an address-computation.

Hypothetically the const-evaluator could carry such info around as the "dynamic type" of the computed value ... i.e. the value itself could be an LLVM-valueref (and thus may not have access to its integer value), or it could be an integer we have computed, but either way, the (dynamic) type (or "tag", if you prefer) would include information about whether this computed value can be sanely converted to a pointer.

See also rust-lang/rust#18294 and perhaps more importantly, rust-lang/rust#24581 or i guess you clearly prefer rust-lang/rust#13973 ;)

[oli-obk]

in case it's dynamically typed

• deprecate type annotations on constants
• there'll be two different systems, constant and runtime, with totally different behavior and syntax
  • lots of confused programmers
  • lots of magic
  • basically a new language for compile time computation :(

in case it's statically typed

"iff" may be a bit stronger than I would like.

actually I think @jakub-'s statement is correct: not all runtime expressions are allowed as constant expressions, but all constant expressions should behave as if they were computed at runtime.

[pnkfelix]

@oli-obk perhaps we are in violent agreement?

I was responding to this proposed rule: "a constant expression should be accepted by the type checker iff its runtime equivalent is."

Which obviously conflicts with "not all runtime expressions are allowed as constant expressions"

[oli-obk]

I actually have a PR in the works that will end all those type confusions forever. I added variants for every builtin integral type and a signed + and unsigned inference type.

I also added a usize and a isize enum that have 32 bit and 64 bit variants and check the tcx for the target architecture during creation and various const eval steps to ensure the proper bit-size and to ensure I didn't screw up somewhere in the middle. So far I have not introduced any breaking changes (except for better error reporting in some locations).