CTFE casts of delegates

[Jonathan M Davis via Digitalmars-d]

On Thursday, January 05, 2017 07:35:52 Eyal Lotem via Digitalmars-d wrote:
> On Thursday, 5 January 2017 at 03:05:21 UTC, Jonathan M Davis
>
> wrote:
> > However, since code that legitimately casts a function to alter
> > its attributes should be _very_ rare, it should also be quite
> > rare that the problem even comes up.
>
> It is very rare to have it in code, but the low-level function
> that does this rare thing (custom assertion function) may be very
> frequently called, indirectly.
>
> > So, I would think that making casts for attributes legal during
> > CTFE wouldn't be a problem (though I could be missing
> > something), but at the same time, if someone is actally asking
> > for such a capability, that's very worrisome. That implies that
> > pure and @nogc are not being used correctly and that casts are
> > being used to try and force the compiler into submission, which
> > risks nasty bugs when the compiler is then making assumptions
> > about the code that are wrong thanks to the fact that it was
> > lied to with casts.
>
> Well, I did explain the reason for this cast. An
> aborting-assertion that discontinues execution (hard kill the
> process).
>
> We expect these assertions to never happen. If they do, we don't
> really care about any GC or impure things that they do just
> before terminating the process.
>
> We don't really want *all* code to be marked gc/impure because it
> directly or indirectly uses such assertions.

Well, you appear to have a use case where such a cast makes sense, but
that's rare. So, while it sucks for you that it doesn't work, it wouldn't
affect most folks, and in most cases, they probably shouldn't be doing it.
Regardless, I have no problem with making such casts legal in CTFE if it can
be done safely (and I think that it can be, since I don't see how pure can
actually be violated during CTFE, and if an @nogc ends up allocating during
CTFE, I don't think that that's actually a problem), since then you're just
in essentially the same boat with CTFE that you are with runtime in that if
you're doing it wrong, you're shooting yourself in the foot, but you're free
to do it if you really want to.

I don't know exactly what you're doing with your custom assertion function,
but my suggestion would be to just use the normal assertion mechanism during
CTFE. e.g.

void customAssert(bool result, lazy msg)
{
    if(__ctfe)
        assert(result, msg);
    else
        (cast(...)&myCustomAssert)(result, msg);
}

The bigger problem is if you're trying to use functions with CTFE which
aren't marked properly as pure or @nogc, and I don't think that there's
really a solution for that right now other than providing an alternate
implementation which doesn't have the problem. In general, the real solution
is to fix it so that the functions are appropriately pure or @nogc rather
than doing any casting (the casting is either a hack/workaround or a
misunderstanding of how the function works), but obviously, that's not
always in your control, and you're either forced to give up on pure or @nogc
for that piece of code or be very sure of what the function actually does
and do the cast as a workaround. So, if you can't fix the function in
question, and you're forced to cast it to use it in the way that you're
trying to use it, then I think that the only solution for CTFE right now
would be to replace it with different functionality during CTFE, which is
far from ideal.

Personally, when something doesn't work with @nogc or pure, and I want to
make my function @nogc or pure, I just comment out the @nogc or pure on the
function and live with it not being @nogc or pure for the moment rather than
casting, since casting seems like a serious risk, especially if the
functionality changes later, and it really can't be @nogc or pure. Then I
try and fix it so that whatever isn't properly @nogc or pure is properly
@nogc or pure, and if I can't, I just put up with the problem until it gets
sorted out. I can understand wanting to go with the casting solution. I just
don't think that it's worth the risk.

In any case, assuming that there's no technical barrier to making the
attribute casts work in CTFE (and it doesn't sound like there is), I don't
see any reason why such casts shouldn't be legal in CTFE (at least with pure
and @nogc). If anything, from what I can tell they're _more_ safe with CTFE
than runtime.

- Jonathan M Davis