newCTFE Status September 2019

[Bert]

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...