Thoughts about "Compile-time types" talk

[Alex]

On Thursday, 16 May 2019 at 13:05:52 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 16 May 2019 at 09:35:16 UTC, Alex wrote:
>> For example, in D we have
>>
>> 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.
>>
>> 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?
>
> I agree with your basic goals.
>
> But there are a few issues:
>
> 1. to avoid the special-casing you need to add type-variables 
> as proper variables in the language. Then you can have 
> functions as meta-level type-constructors.
>
> 2. you need to provide a construct for ensuring that a value is 
> resolved at compile time.
>
> 3. how do you ensure that the library code you write is 
> structured in a way that doesn't seem to arbitrarily break?
>
> 4. corollary of 3, how to you ensure that library code doesn't 
> generate slow code paths spent on resolving typing information 
> at runtime?
>
>
> Anyway, I don't disagree with your goals, but you would have a 
> completely different language.

Yeah, I didn't mean that that D it self would be this. My point 
was that this is where languages are ultimately headed.  Knowing 
where we are going helps us get there.

D itself might not be able to do this but the goal would be to 
get closer to the ideal. How that is achieved properly for D is 
not in my domain of expertise.