On Thursday, 5 September 2019 at 10:55:30 UTC, Dominikus Dittes Scherkl wrote:
>
> 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!

Phobos...

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

On Saturday, 7 September 2019 at 10:17:41 UTC, Jacob Shtokolov wrote:
> On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
>> P.S. your support is always appreciated.
>
> Just wondering, would it make sense to start a new crowdfunding campaign dedicated to newCTFE? I think this is quite an important feature for the compiler. I would donate. Previously we had campaigns for Code-D VSCode extension and D Lang forums server.
>
> Why don't make it again for this amazing work?

I would certainly not antagonize this :)

With a bit of funding I'd be able to take time off work,
And give newCTFE the last push and polish it needs.

On Thursday, 5 September 2019 at 21:19:07 UTC, Timon Gehr wrote:
>
> Another thing that works well is to just use the exception handling mechanism of the host language.


The host language in this case is newCTFE-IR.
And that is intentionally quite close to what a simple RISC processor would provide.
As it is supposed to be just-in-time compile-able with minimal overhead.
Therefore it does not provide exception handling support, and likely never will.
Since that would mean every backend would have to provide a way to stack catch-clauses and such.

On Thu, 05 Sep 2019 10:55:30 +0000, Dominikus Dittes Scherkl 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!

If `a` calls `b` calls `c` at compile-time, `c` can throw something that `a` can catch, interpret, and rethrow with a more meaningful message/ context.

I'd argue that it is bad practice to have a thrown Exception at CT that doesn't result in a failed compilation; compile-time exceptions should be treated by the programmer like failed assertions - something has gone wrong that needs to be fixed before deployment.

It is possible though:

---
int fail() { throw new Exception("error"); }

int func() {
    try {
        return fail();
    } catch (Exception) {}
    return 0;
}

enum a = func();
void main() {}
---


--Ryan

Great work!

Will newCTFE able to work in -betterC mode? By now CTFE engine have some limitations at this point: https://forum.dlang.org/thread/djmdhhcuwaroznpkfjis@forum.dlang.org?page=1

On Thursday, 12 September 2019 at 11:57:35 UTC, rjframe wrote:
> I'd argue that it is bad practice to have a thrown Exception at CT that doesn't result in a failed compilation; compile-time exceptions should be treated by the programmer like failed assertions

I strongly disagree with this.

CTFE is explicitly not supposed to be a separate universe with its own standards of behavior; it's supposed to just be "functions, executed at compiletime". Crucially, the *same* functions as at runtime, hence opening up the use of Phobos.

Phobos, which silently throws and catches exceptions internally.

On Thursday, 12 September 2019 at 11:57:35 UTC, rjframe wrote:
> On Thu, 05 Sep 2019 10:55:30 +0000, Dominikus Dittes Scherkl 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!
>
> If `a` calls `b` calls `c` at compile-time, `c` can throw something that `a` can catch, interpret, and rethrow with a more meaningful message/ context.
>
> I'd argue that it is bad practice to have a thrown Exception at CT that doesn't result in a failed compilation; compile-time exceptions should be treated by the programmer like failed assertions - something has gone wrong that needs to be fixed before deployment.
>
> It is possible though:
>
> ---
> int fail() { throw new Exception("error"); }
>
> int func() {
>     try {
>         return fail();
>     } catch (Exception) {}
>     return 0;
> }
>
> enum a = func();
> void main() {}
> ---
>
>
> --Ryan


The problem is that a function that runs in ctfe can also be used to run at run time... the code at runtime might be designed to use exceptions and then your arbitrary limitation for simplicity will break ctfe code and then ctfe won't be just like rt any more. This will then require hacks to get things to work out...

On Thursday, 12 September 2019 at 20:25:12 UTC, Oleg B wrote:
> Great work!
>
> Will newCTFE able to work in -betterC mode? By now CTFE engine have some limitations at this point: https://forum.dlang.org/thread/djmdhhcuwaroznpkfjis@forum.dlang.org?page=1

It's possible but highly unlikely.
BetterC throws the error when the function goes through SemA (semantic analysis) before ctfe can get to evaluating the functions.

Changing that would require a special pre-codegen pass And would be a really invasive change.

On Tuesday, 10 September 2019 at 11:53:28 UTC, Stefan Koch wrote:
> With a bit of funding I'd be able to take time off work,
> And give newCTFE the last push and polish it needs.

How much would you need?