CTFE limitation on reinterpreting cast

Rambutan s56l6zk0w at mozmail.com
Tue Sep 29 18:23:27 UTC 2026


On Tuesday, 29 September 2026 at 11:19:15 UTC, user1234 wrote:
> I think this is not related to CTFE, that should just work in a 
> `@system` scope. In other words, congrats you've found a bug.

Yes, seems like that.

The CTFE error message specifically forbids a narrow kind of cast 
that doesn't change the underlying pointer, a "reinterpreting 
cast". To me this seems to be a design choice not an accident.

Any information about this design choice will be gratefully 
received. In the absence of that I will speculate some.

Using what a pointer obtained through a "reinterpreting cast" 
points to is dangerous in general, with some exceptions of 
course. So maybe forbidding reinterpreting casts in CTFE is a 
security decision to avoid this dangerous use of reinterpreted 
pointers during compilation.

This security decision is overkill because it prevents harmless 
reinterpreting casts of pointers.

C can initialize arrays of structs at compile time to contain 
cast pointers to global data but D cannot. Allowing D to do this 
would be allowing harmless reinterpreting casts at compile time.

What makes a reinterpreting cast harmless in CTFE? When the 
reinterpreted pointer is not used to access what it refers to. 
When it is not used for indirection in any way at compile time.

So allowing "reinterpreting casts" for pointers, and disallowing 
indirection for reinterpreted pointers is a far better CTFE rule.

This would likely enable D to more-or-less copy any C-style 
compile-time initialization of big global arrays, which would be 
great in a mixed source project that started as all C.











More information about the Digitalmars-d mailing list