How should the term "comptime value" be defined?

Help
21

I assume you meant &b?

It is not similar at all, the only way you could claim so would be “comptime is involved”, but that is vague beyond useless.

They are completely different interactions within comptime, &type is a const pointer to comptime immutable data, data which can only exist at comptime.

comptime var b...; &b is a non-const pointer to comptime mutible data. This is memory that can only exist at comptime.

To elaborate on the differences:

The former can easily be identified by the compiler via the type
the latter cannot, at least not currently.

Prior to, I think 0.16, both were actually a compile error, that was changed because the following.

The former allows simplifying code, for example, type information contains plenty of data that could be used at runtime, you can just do that so long as the comptime only types are behind pointers, which most info types already do.

It also simplifies the compiler among many other type/comptime semantic changes that occurred at the same time (most are not visible or breaking).

Why would you want that same behaviour for comptime var?

Most code like this intends to produce runtime useable data or comptime only data. The current behaviour provides a clear boundary illustrated by a compile error if you break it from either direction.

Whereas making the behaviour the same as pointers to comptime types, would shift the error for one side deeper into analysis, producing a worse error, or even no error if you happen to not de reference the pointer.

2 Likes
22

Thank all for the discussion. I get a better understanding of comptime values now,

A summary.

  • Some pointers to runtime mutable values (such as global var declarations) can be comptime.
  • Pointers of a comptime immutable value can be stored in a runtime pointer (assume it is cp).
    • If the type of the comptime immutable value is a comptime-only types (such as type and comptime_int), then the compiler disallows @constCast(cp).* = newVal dereferencing the runtime pointer.
    • If the type of the comptime immutable value is not a comptime-only types, then the compiler allows dereferencing the runtime pointer, and even @constCast(cp).* = newVal, though the operation is undefined behavior.
  • Pointers to comptime mutable values cannot be stored in a runtime pointer.
23

Minor semantic corrections, things that could be inferred, but for other readers best be explicit:

runtime mutable

More generally it disallows cp.*, reading a comptime only type at runtime is also impossible.

similarly, more generally it allows cp.*, reads vs writes is a separate matter of the pointers constness.

It is also a compile error, not undefined behaviour.

cannot be stored at runtime period, regardless of if its behind any number of pointers or not, but I suspect this is just a typo.

2 Likes
24

True.

similarly, more generally it allows cp.*, reads vs writes is a separate matter of the pointers constness.

It is also a compile error, not undefined behaviour.

It does compile.

25

oops, i was still thinking of comptime only types.
with runtime allowed types yes it is undefined behaviour.

But that is not related to the value/ptr being comptime known, rather it is an invalid use of @constCast.

2 Likes