Is betterC affect to compile time?

[bauss]

On Thursday, 25 July 2019 at 18:06:02 UTC, Jonathan Marler wrote:
> On Thursday, 25 July 2019 at 12:46:48 UTC, Oleg B wrote:
>> On Thursday, 25 July 2019 at 12:34:15 UTC, rikki cattermole 
>> wrote:
>>> Those restrictions don't stop at runtime.
>>
>> It's vary sad.
>>
>> What reason for such restrictions? It's fundamental idea or 
>> temporary implementation?
>
> Yes it is very sad.  It's an implementation thing.  I can guess 
> as to a couple reasons why it doesn't work, but I think there's 
> a few big ones that contribute to not being able to use certain 
> features at compile-time without having it introduce things at 
> runtime.

Anything you do at compile-time should never produce anything at 
runtime UNLESS it's a field created or something created using 
mixin.

D's betterC is pretty useless if you can't use D to its fullest 
at compile-time regardless of whether you're compiling with 
betterC or not.

It takes the one thing away from D that it does better than other 
languages, which is CTFE and metaprogramming.