On Monday, 19 August 2019 at 23:04:23 UTC, Walter Bright wrote:
> On 8/19/2019 7:02 AM, Ethan wrote:
>> Even just a patch to fix array memory handling behind the scenes would be great.
>
> The memory handling could be fixed if the CTFE's allocated AST's were all allocated from a separate pool, and marked as such. Then, the returned AST from CTFE can be scanned and every marked node replaced. Then, the entire pool can be discarded.
>
> Should be fairly simple to implement.

At least last time I tried that, (which was 2.8 years ago), I ran into problems with deciding which nodes to keep. As CTFE can trigger semantic() on FunctionDeclarations, and all of the nodes created there have to be kept, even though they might not be referenced from the ctfe result.

On 8/19/2019 4:04 PM, Walter Bright wrote:
> Should be fairly simple to implement.

https://github.com/dlang/dmd/pull/10343

On 8/20/2019 5:38 PM, Stefan Koch wrote:
> At least last time I tried that, (which was 2.8 years ago), I ran into problems with deciding which nodes to keep. As CTFE can trigger semantic() on FunctionDeclarations, and all of the nodes created there have to be kept, even though they might not be referenced from the ctfe result.

Doing a reference count on the Region allocator should do the trick.

On Saturday, 24 August 2019 at 08:23:52 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/10343

I will eagerly test this out in the very near future.

On Saturday, 24 August 2019 at 08:23:52 UTC, Walter Bright wrote:
> On 8/19/2019 4:04 PM, Walter Bright wrote:
>> Should be fairly simple to implement.
>
> https://github.com/dlang/dmd/pull/10343

Does this fix: https://issues.dlang.org/show_bug.cgi?id=1382 ? I would test it myself, but last time I tried, my computer hanged.

On 8/27/2019 7:12 AM, RazvanN wrote:
> Does this fix: https://issues.dlang.org/show_bug.cgi?id=1382 ? I would test it myself, but last time I tried, my computer hanged.

Not yet, it's just a start.

On Tuesday, 27 August 2019 at 14:12:50 UTC, RazvanN wrote:
> On Saturday, 24 August 2019 at 08:23:52 UTC, Walter Bright wrote:
>> On 8/19/2019 4:04 PM, Walter Bright wrote:
>>> Should be fairly simple to implement.
>>
>> https://github.com/dlang/dmd/pull/10343
>
> Does this fix: https://issues.dlang.org/show_bug.cgi?id=1382 ? I would test it myself, but last time I tried, my computer hanged.

newCTFE will fix this.
Infact for the example posted in the bug, it already does.

On Wednesday, 28 August 2019 at 21:31:45 UTC, Walter Bright wrote:
> On 8/27/2019 7:12 AM, RazvanN wrote:
>> Does this fix: https://issues.dlang.org/show_bug.cgi?id=1382 ? I would test it myself, but last time I tried, my computer hanged.
>
> Not yet, it's just a start.

The region allocater can be used in newCTFE as well.
So in this case our work is synergistic.

Any more work poured into the interpret.d is likely to be superseeded by newCTFE in a few months.

On Thursday, 15 August 2019 at 21:42:47 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I had 2 weeks of vacation recently, and I used them to work on newCTFE again.
> [...]
>
> That said, I am hopeful to be able to release newCTFE in 2020!

Hi Stefan,

Great that you're still getting some time to work on this!

By coincidence, I just ran into a case. I'm curious, will newCTFE enable the usage below?

------------------
$ cat ctfe_case.d
struct C
{
    import std.conv : to;
    string s = double.init.to!string;   // Fails to compile.
}

void main()
{
    import std.stdio;
    C c;
    writeln(c.s);
}

$ dmd ctfe_case.d
/Library/D/dmd/src/phobos/std/exception.d(515): Error: uncaught CTFE exception std.format.FormatException("Cannot format floating point types at compile-time")
ctfe_case.d(4):        called from here: to(nan)
---------------

Using a similar code construct in a function works fine:

----------------
$ cat ctfe_case2.d
void main()
{
    import std.stdio;
    import std.conv : to;

    string s = double.init.to!string;
    writeln(s);
}
$ dmd ctfe_case2.d
$ ./ctfe_case2
nan
-----------------

--Jon

On Saturday, 31 August 2019 at 21:44:38 UTC, Jon Degenhardt wrote:
> By coincidence, I just ran into a case. I'm curious, will newCTFE enable the usage below?

This isn't actually a CTFE engine thing, just the library implementation.

The current CTFE engine can do it if you use a different library function to do the conversion (Stefan I believe has ported one from C to D before and it is ... somewhere...).

The reason it won't do it now is that it calls out to a C function to format floating point, and CTFE - new and old - can only evaluate D functions.

> Using a similar code construct in a function works fine:
>
> ----------------
> $ cat ctfe_case2.d

this one is not ctfe btw.