Thoughts about "Compile-time types" talk

[NaN]

On Wednesday, 15 May 2019 at 19:09:27 UTC, H. S. Teoh wrote:
> On Wed, May 15, 2019 at 06:31:57PM +0000, NaN via Digitalmars-d 
> wrote:
>
> Case (1) is relatively straightforward to unify with regular if.
>
> Case (2) would seem to be solely in the domain of static if, 
> and I don't see much point in trying to unify it with regular 
> if, even if such were possible.  For example, static if can 
> appear outside a function body, whereas regular if can't. 
> Static if can therefore be used to choose a different set of 
> declarations at the module level. If we were to hypothetically 
> unify that with regular if, that would mean that we have to 
> somehow support switching between two or more sets of 
> likely-conflicting declarations at *runtime*.  I don't see any 
> way of making that happen without creating a huge mess, unclear 
> semantics, and hard-to-understand code -- not to mention the 
> result is unlikely to be very useful.
>
> So I'd say static if in the sense of (2) should remain as-is, 
> since it serves a unique purpose that isn't subsumed by regular 
> if.  Static if in the sense of (1), however, can probably be 
> unified with regular if.

So what you really have is (1) which is an optimisation problem. 
Enable parameters that can be either CT or RT, so that the same 
code can be used in each instance, and the compiler can do dead 
code elimination when a parameter is CT.

Or (2), which is conditional compilation, which stays as it is.

So it is more a question of unifying CT & RT parameters than it 
is maybe unifying CT & RT language constructs. In fact maybe it 
doesnt do anything for the later? So it comes down to enabling 
parameters that can do both CT and RT so the compiler can do dead 
code elimination on those parameters if CT. Because at the moment 
the choice of CT?RT is fixed by the function being called.