Thoughts about "Compile-time types" talk

[NaN]

On Thursday, 16 May 2019 at 09:35:16 UTC, Alex wrote:
> On Thursday, 16 May 2019 at 08:12:49 UTC, NaN wrote:
>
> No, you don't get it.

Unsurprisingly I feel that neither do you, at least you dont get 
what Im saying, or rather you think Im saying something that Im 
not.


> We are talking about a hypothetical compiler that doesn't have 
> to have different contexts. In D, the contexts arbitrarily 
> separated in the language...

I don't see how it can not have different contexts, it runs at 
compile time, produces a binary and that runs at runtime. You can 
hide that fact, make it so code looks and works the same in each 
context as much as possible. But you cant not have that be what 
actually happens.


> What we are ultimately talking about here is that CT and RT is 
> not two different concepts but one concept with some very 
> minute distinction for RT.

Yes, exactly my point, there will be differences. Andrei did a 
talk on why C++s static if was next to useless because it 
introduces a new scope. That's all I was pointing out, regular if 
and static if behave differently in D. And with good reason.


> As a programmer you shouldn't care if something is CT or RT and 
> hence you shouldn't even know there is a difference.

Like most things that "just work" you dont care until you do.


> What are you saying is that you have one if and two contexts. 
> What I'm saying is  hat you have one if and one context. That 
> the CT programming and runtime programming are NOT treated as 
> being two different universes with some overlap but the same 
> universe with a slight boundary.

100% it'd be great if RT/CT were "same rules apply", but i was 
just pointing out one of the "boundaries" where that is currently 
not the case.


> enum x = 4;
> and
> int y = 4;
>
> That is explicitly two different programming contexts. On CT 
> and the other RT. But that is the fallacy. They are EXACTLY 
> identical programmatically.

static if (x) {}
and
if (y) {}

Are currently not identical grammatically. One introduces a new 
scope and one does not.


> Only when y is modified at some point later in the code does 
> things potentially change. enum says we will never change x at 
> CT... but why can't the compiler figure that out automatically 
> rather than forcing us to play by it's rules and have a 
> separate context?

Defining a constant is not you informing the compiler you wont 
change the value, it's you telling the compiler to make sure that 
you dont. That cant be inferred by the compiler because the act 
of modifying it would destroy the inference that it should not be 
modified. It's catch 22.