CTFE and Wasm

[Dukc]

On Saturday, 30 April 2022 at 07:08:48 UTC, Ola Fosheim Grøstad 
wrote:
> I understand why both D and C++ users make a fuzz about CTFE, 
> it gives them a feeling of being able to extend the type system 
> or language in a way they are used to. However they are still 
> at wn disadvantage to more powerful languages that allow 
> construction of new types at runtime and do CTFE as an 
> optimization.

No, we're not at a disadvantage. If CTFE was just an 
optimisation, it'd mean we could not use it to compute values 
that have to be compile-time by definition. Example:

```D
//CTFE-able function
@safe pure size_t neededSize(size_t a, size_t b)
{ //Whatever...
}

struct SomeTemplateStruct(T)
{ //This wouldn't be possible without CTFE built in to semantics
   ubyte[neededSize(T.sizeof, 4)] anArray;

   //Neither would this
   static if(neededSize(T.sizeof, 8))
   { //...
   }
}
```

>
> Reason 1: compilation performance.
> Reason 2: poor debugging tooling.
>
> I'd say you don't have a proper CTFE solution until you can set 
> breakpoints in all functions and see what goes on.

You can still execute the CTFE-able functions at runtime when 
these are what you prefer.

And nothing prevents the compiler backend from optimising the 
calculations to compile time even when they are semantically 
runtime, which I understand is what you're advocating.

>
> One possibility is to reuse WASM infrastructure by compiling 
> CTFE functions to WASM and use source maps for debugging.
>
> What do you think?

Complex and not needed, for reasons above.