Hi Guys,

The issues with closures seem to be resolved.
It turns out it was not an issue with the closure handling but it failed for non-explicitly initialized structs.

While running my tests I discovered that I forgot to implement exception-handling :-/.
That's why I am currently working on implementing it.

Since personally I do _try_ to avoid Exceptions.
I do not have a good mental model of them.
Therefore Implementing them might take a while until it's correct.

Currently I am trying to model a thrown Exception with a specially flagged return value, which will go up into the catch-clause-stack instead, of being returned to the caller.

The implementation is work in progress, so there are no experimental results yet.
If anyone sees a flaw in this model, please alert me to it.

Cheers,

Stefan

P.S. your support is always appreciated.

On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
> Hi Guys,
>
> The issues with closures seem to be resolved.
> It turns out it was not an issue with the closure handling but it failed for non-explicitly initialized structs.
>
> While running my tests I discovered that I forgot to implement exception-handling :-/.
> That's why I am currently working on implementing it.
>
> Since personally I do _try_ to avoid Exceptions.
> I do not have a good mental model of them.
> Therefore Implementing them might take a while until it's correct.
>
> Currently I am trying to model a thrown Exception with a specially flagged return value, which will go up into the catch-clause-stack instead, of being returned to the caller.
>
> The implementation is work in progress, so there are no experimental results yet.
> If anyone sees a flaw in this model, please alert me to it.
>
> Cheers,
>
> Stefan
>
> P.S. your support is always appreciated.

Always happy to see these updates - you're doing great and important work! :)

--
  Simen

On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
> Hi Guys,
>
> The issues with closures seem to be resolved.

See?!! Just keep on churning :-)

Bastiaan.

On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
> Currently I am trying to model a thrown Exception with a specially flagged return value, which will go up into the catch-clause-stack instead, of being returned to the caller.

This reminds me of an article I once found, you might be interested in it:
https://nim-lang.org/araq/quirky_exceptions.html

On Thursday, 5 September 2019 at 09:32:38 UTC, Dennis wrote:
> On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
>> Currently I am trying to model a thrown Exception with a specially flagged return value, which will go up into the catch-clause-stack instead, of being returned to the caller.
>
> This reminds me of an article I once found, you might be interested in it:
> https://nim-lang.org/araq/quirky_exceptions.html

Thank you very much for sharing that link.
Their approach is better than what I had originally since, that way catch-blocks can be created after the Call. and there is no need to build closures.

On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
> While running my tests I discovered that I forgot to implement exception-handling :-/.
?!?
Shouldn't an exception thrown during CTFE simply put out it's message as compilation error and stop there? - Otherwise the result can only be some bogous binary that's completely useless...

On Thursday, 5 September 2019 at 10:17:53 UTC, Dominikus Dittes Scherkl wrote:
> On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
>> While running my tests I discovered that I forgot to implement exception-handling :-/.
> ?!?
> Shouldn't an exception thrown during CTFE simply put out it's message as compilation error and stop there? - Otherwise the result can only be some bogous binary that's completely useless...

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.

Life is though sometimes :)

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!

On 05.09.19 12:15, Stefan Koch wrote:
> On Thursday, 5 September 2019 at 09:32:38 UTC, Dennis wrote:
>> On Thursday, 5 September 2019 at 07:33:21 UTC, Stefan Koch wrote:
>>> Currently I am trying to model a thrown Exception with a specially flagged return value, which will go up into the catch-clause-stack instead, of being returned to the caller.
>>
>> This reminds me of an article I once found, you might be interested in it:
>> https://nim-lang.org/araq/quirky_exceptions.html
> 
> Thank you very much for sharing that link.
> Their approach is better than what I had originally since, that way catch-blocks can be created after the Call. and there is no need to build closures.

Another thing that works well is to just use the exception handling mechanism of the host language.

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?