newCTFE Status November 2018

[Stefan Koch]

On Monday, 10 December 2018 at 11:04:47 UTC, kinke wrote:
> On Sunday, 9 December 2018 at 15:23:30 UTC, Joakim wrote:
>> On Sunday, 9 December 2018 at 14:48:31 UTC, H. S. Teoh wrote:
>>> Looks like we'll somehow need a way to tell the CTFE engine 
>>> what the target arch should be, and when something doesn't 
>>> match the host type, it should run a software emulation 
>>> instead of using the host's `real`.
>>
>> Yes, Iain says gdc already uses such multi-precision 
>> soft-float, and kinke mentioned earlier in this thread that 
>> he'd like to do the same with ldc. The reason I brought this 
>> issue up is that Stefan initially mentioned doing something 
>> similar for dmd.
>
> My point being that it's not just the CTFE engine that needs to 
> support compile-time reals (real_t) of at least target `real` 
> precision. FP literals have to be parsed by the front-end, need 
> to be printable to string (template instantiations, header 
> generation etc.) and stored, and this is currently taken care 
> of by the `real_t` type and the dmd.root.ctfloat module.
> So ideally, newCTFE would just keep on relying on that 
> infrastructure, just like the current interpreter (+ 
> dmd.builtin module) does, instead of trying to reinvent the 
> wheel.

ctfloat depends on the C runtime, and therefore it's 
implementation dependent.
I'd rather go with an implementation which I have verified myself.
And where I can give meaningful statements about what it can, and 
can't support.

I'd love to not re-invent the weel; But we don't have a wheel.