Are we on the simplest path for working with compile time entities?

Stefan Koch uplink.coder at gmail.com
Sat Sep 26 10:23:31 UTC 2020


On Friday, 25 September 2020 at 15:25:16 UTC, Andrei Alexandrescu 
wrote:
>
> Reference: https://github.com/dlang/dmd/pull/11792
>
> This is a small-cost and small-impact change. It's very rare 
> the size gets used with any frequency during compilation. A 
> small step that is somewhat lateral.
>
> The prize is https://issues.dlang.org/show_bug.cgi?id=9945.
>
> I also added what is an obviously simpler way to go about 
> things. It's not like a type changes size and alignment during 
> the program: https://issues.dlang.org/show_bug.cgi?id=21276
>
> More related stuff:
>
> https://issues.dlang.org/show_bug.cgi?id=21277
> https://issues.dlang.org/show_bug.cgi?id=21278

I not concerned about the size of this individual change.
I am concerned about the direction.

Where do we end up if we extrapolate the hypothetical vector of 
this change?
I imagine we would end up with many tiny additions trickling in.

And those only concern types.
There are other compile time properties which you would like to 
query and reason about.
Such as the content of modules, the names of variables.
symbol scope (__traits(parent)) etc.

Also this increases the surface area of the language rather than 
increasing the depth.

Having to use tinfo.tsize;
instead of being able to use T.sizeof like you would in a 
template.
Which increases cognitive load by requiring more memory.



More information about the Digitalmars-d mailing list