CTFE casts of delegates

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Wed Jan 4 19:05:21 PST 2017


On Wednesday, January 04, 2017 16:19:52 Seb via Digitalmars-d wrote:
> On Wednesday, 4 January 2017 at 16:06:11 UTC, Stefan Koch wrote:
> > On Wednesday, 4 January 2017 at 08:45:59 UTC, Eyal Lotem wrote:
> >> On Tuesday, 3 January 2017 at 09:44:38 UTC, Stefan Koch wrote:
> >>> I think that I can provide a dmd patch that would allow the
> >>> casts you want at ctfe.
> >>> However I would not propose it for inclusion myself.
> >>
> >> A cast that only fiddles with function attributes like @nogc
> >> should be perfectly safe, shouldn't it?
> >
> > Honestly I am not sure about it.
> > I guess I could enable this back-door for you and others.
>
> This back-door already exists, see e.g.:
>
> https://github.com/nordlow/phobos-next/blob/master/src/dbgio.d#L13
>
> and
>
> http://forum.dlang.org/post/nq4eol$2h34$1@digitalmars.com
>
> > Patch will follow in the next days, I am not sure if it will be
> > merged though.
>
> There is assumeWontThrow
> (https://dlang.org/phobos/std_exception.html#.assumeWontThrow) in
> std.exception, so I think the chances for assumeNogc or
> assumePure aren't that bad ;-)

Well, assumeWontThrow is a completely different animal. There is a perfectly
legitimate way to make a function be nothrow while still call functions that
can throw exceptions - you have a catch(Exception) block in it and don't
throw any exceptons or call any non-nothrow functions outside of it. No such
thing exists for @nogc or pure. Those are type system issues, and in order
to make something @nogc that's calling functions that aren't @nogc or to
make something pure that's calling functions that aren't pure, you have to
subvert the type system. If the programmer does it, they have to make sure
that they do so in a way that doesn't violate the guarantees that the
compiler makes about @nogc or pure - which isn't necessarily easy. And in
general, it's a big red flag when code uses casts to make anything @nogc or
pure. So, putting something in the standard library specifically to support
such an idiom really doesn't seem like a good idea. Only experts should be
doing it, and even then, they should reconsider.

Now, as to having the ability to have casting muck with pure or @nogc with
CTFE, I don't know. It would be nice to have the same capabilties at compile
time that you have at runtime, and if a function is legitimately and
correctly using casts to deal with @nogc or pure, then it sucks that it
can't be done with CTFE. 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.

>From an @safety perspective though, I don't see why it would be an
implementation issue to support such casts durintg CTFE. IIRC, you can't
mess with global or static variables in CTFE if they're mutable, and you
can't call C functions. So, in essence, _everything_ is pure during CTFE.
If I understand correctly, any attempt to call anything that was not
legitimately pure would fail for not being CTFE-able. And since AFAIK, you
pretty much _have_ to use the GC for everything during CTFE (you certainly
can't call malloc, and most pointer operations are forbidden, making stack
allocators and whatnot infeasible), I don't think that having a function be
@nogc when it really isn't @nogc would actually matter during CTFE.

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.

- Jonathan M Davis



More information about the Digitalmars-d mailing list