newCTFE Status September 2019

[Jonathan M Davis]

On Thursday, September 5, 2019 4:55:30 AM MDT Dominikus Dittes Scherkl via 
Digitalmars-d wrote:
> On Thursday, 5 September 2019 at 10:23:18 UTC, Stefan Koch wrote:
> > Well no, if you have CTFE code up the stack which catches the
> > Exception then it's fine.
> > It's only a problem if the Exception would escape out of the
> > ctfe-entry-point.
> >
> > Therefore I do have to provide the means for Exceptions to be
> > thrown and caught within ctfe.
>
> OMG. Do we really want a program to compile that throws and
> catches exceptions _during compilation_? Who programs such crappy
> shit should suffer worse than a simple compile error!

And why should code that's run at compile time be any different from code
that's run at runtime with regards to the ability to handle exceptions -
especially when CTFE supports a large portion of the language and allows for
arbitrarily complex code? The only major differences are that some things
can't be done during CTFE that can be done during runtime, and most CTFE is
operating on known input. Yes, ideally, you wouldn't be getting any
exceptions with known input, but if the code is sufficiently complex, it
wouldn't necessarily be easy to know that exceptions were involved if the
code handled them, and it could be extremely annoying for such code to fail
at compile time when it would succeed at runtime - especially if you're
calling code that you have no control over. Also, it _is_ possible to have
input at compile time which is not known ahead of time and which can vary
between compilation runs. By using string imports, it's possible to have
your program operating on arbitrary input at compile time just like you'd
get at runtime, and not being able to have exceptions function normally
under such circumstances could be crippling.

I definitely agree that the vast majority of CTFE code should not involve
exceptions at all, because the vast majority of it operates on known inputs,
and most of it is simple enough that you can easily avoid having exceptions
be involved, but just because most CTFE code shouldn't be doing anything
with exceptions doesn't mean that _no_ CTFE code should be doing anything
with exceptions. Ideally, it would be possible to do everything at compile
time that you can do at runtime. That's not currently possible, and it will
likely never be possible, but disallowing a feature that we can make work is
just needlessly restricting what we can do.

Also, it's currently possible with CTFE today to throw and catch exceptions.
So, if newCTFE can't handle it, then it won't be able to do as much as CTFE
can currently do, which means that without falling back to the current CTFE
in such a case, newCTFE would not be a viable replacement for the current
CTFE engine.

- Jonathan M Davis