Good day ladies and gentleman,

it is my distinct please to announce that a new feature just landed in newCTFE.

!!! DELEGATES !!!

this means the following code will now work:
int square_of_x_plus_x(int x) pure
{
    int passThrough(int y) pure
    {
        assert(x == y);
        int y2 = x;
        assert(y2 == y);

        int fnC() pure
        {
            auto z = (x * y);
            assert(y2 == x);
            assert(x == y);
            return z;
        }
        return fnC();
    }
    return x + passThrough(x);
}

pragma(msg, square_of_x_plus_x(7));
static assert(square_of_x_plus_x(5) == (5*5)+5);

the reason why this was quite tricky to implement is that
in the newCTFE architecture there is no concept of a function touching
the stack-frame of another function _at all_.
(Infact there is  no conventional stack, rather the virtual registers themselves stack)
Sharing of the stack frames gets emulated via a hidden parameter and a linked-list structure.

Cheers,
Stefan

On Wednesday, 13 June 2018 at 05:57:31 UTC, Stefan Koch wrote:
> Good day ladies and gentleman,
>
> it is my distinct please to announce that a new feature just landed in newCTFE.
>
> !!! DELEGATES !!!
>
> this means the following code will now work:
> int square_of_x_plus_x(int x) pure
> {
>     int passThrough(int y) pure
>     {
>         assert(x == y);
>         int y2 = x;
>         assert(y2 == y);
>
>         int fnC() pure
>         {
>             auto z = (x * y);
>             assert(y2 == x);
>             assert(x == y);
>             return z;
>         }
>         return fnC();
>     }
>     return x + passThrough(x);
> }
>
> pragma(msg, square_of_x_plus_x(7));
> static assert(square_of_x_plus_x(5) == (5*5)+5);
>
> the reason why this was quite tricky to implement is that
> in the newCTFE architecture there is no concept of a function touching
> the stack-frame of another function _at all_.
> (Infact there is  no conventional stack, rather the virtual registers themselves stack)
> Sharing of the stack frames gets emulated via a hidden parameter and a linked-list structure.
>
> Cheers,
> Stefan

That's very nice! Out of curiosity, what was the reason to avoid a conventional stack? Or was it a consequence more than a design decision? (If you've explained it before, feel free to just throw the old post at me)

On Wednesday, 13 June 2018 at 05:57:31 UTC, Stefan Koch wrote:
> Good day ladies and gentleman,
> it is my distinct please to announce that a new feature just landed in newCTFE.
> !!! DELEGATES !!!

Nice!

On Wednesday, 13 June 2018 at 06:10:26 UTC, Cym13 wrote:
>
> That's very nice! Out of curiosity, what was the reason to avoid a conventional stack? Or was it a consequence more than a design decision? (If you've explained it before, feel free to just throw the old post at me)

It was an initial design decision. (I addressed it briefly in my 2017 talk on newCTFE)
https://www.youtube.com/watch?v=crHnumzsLUs&t=2420

The main reason was to avoid the debugging nightmare that messing with the stack-pointer causes. I thought the most effective way to not have this problem was to simply eliminate the stack pointer.
Another reason is that I am noticing a tendency in real hardware to have multiple-stacked versions of the register set. Doing the same with my virtual cpu would be forward compatible :)

All in all I do not regret that decision at all.

It doubtlessly saved weeks of debugging!
(And harmonizes delegates with closures (since in newCTFE _all_ delegates have to be closures.))

Cheers,
Stefan