Here it is:

https://github.com/dlang/druntime/pull/1710

It relieves code that uses assert from needing the GC. I think all Errors should be singletons - multiple objects in that hierarchy arguably make no sense. But of course there are many situations out there. If this breaks your code, please holler.


Andrei

On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>
> But of course there are many situations out there.

Wouldn't it break chained assertion errors?

On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
> I think all Errors should be singletons - multiple objects in that hierarchy arguably make no sense.

With that logic, why does Throwable have the field "next"?

On Monday, 12 December 2016 at 16:35:22 UTC, safety0ff wrote:
> Wouldn't it break chained assertion errors?

An Error is unrecoverable anyway, if such a case arises it can always just abort the program immediately.

On 12/12/16 17:51, Andrei Alexandrescu wrote:
> Here it is:
>
> https://github.com/dlang/druntime/pull/1710
>
> It relieves code that uses assert from needing the GC. I think all
> Errors should be singletons - multiple objects in that hierarchy
> arguably make no sense. But of course there are many situations out
> there. If this breaks your code, please holler.
>
>
> Andrei

As you may know, Weka has a huge GC aversion. Despite that fact, I fail to see the improvement such a change would bring. The only situation under which using the GC is not harmful is when the entire process is about to go kaboom anyways.

Now, if you'd make regular Exceptions GC free....

Shachar

On 12/12/16 17:51, Andrei Alexandrescu wrote:
> Here it is:
>
> https://github.com/dlang/druntime/pull/1710
>
> It relieves code that uses assert from needing the GC. I think all
> Errors should be singletons - multiple objects in that hierarchy
> arguably make no sense. But of course there are many situations out
> there. If this breaks your code, please holler.
>
>
> Andrei

I'll just add that we're not using AssertError anyways. We found that the various scope(failure) and scope(exit) that run in such cases significantly detract from the ability to debug what actually happened.

Our assert immediately terminates the process.

Shachar

On 12/12/2016 11:35 AM, safety0ff wrote:
> On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>>
>> But of course there are many situations out there.
>
> Wouldn't it break chained assertion errors?

Once a type in Error's cone gets thrown there is no guarantee of unwinding, hence no guarantee of chaining. -- Andrei

On 12/12/2016 12:43 PM, Guillaume Boucher wrote:
> On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>> I think all Errors should be singletons - multiple objects in that
>> hierarchy arguably make no sense.
>
> With that logic, why does Throwable have the field "next"?

Probably only Exception should. -- Andrei

On 12/12/2016 02:54 PM, Shachar Shemesh wrote:
> On 12/12/16 17:51, Andrei Alexandrescu wrote:
>> Here it is:
>>
>> https://github.com/dlang/druntime/pull/1710
>>
>> It relieves code that uses assert from needing the GC. I think all
>> Errors should be singletons - multiple objects in that hierarchy
>> arguably make no sense. But of course there are many situations out
>> there. If this breaks your code, please holler.
>>
>>
>> Andrei
>
> As you may know, Weka has a huge GC aversion. Despite that fact, I fail
> to see the improvement such a change would bring.

Why am I not surprised :o).

> The only situation
> under which using the GC is not harmful is when the entire process is
> about to go kaboom anyways.

You get to use assert without needing to link in the GC.

> Now, if you'd make regular Exceptions GC free....

That will come too.


Andrei

On 12/12/16 12:59 PM, Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/12/2016 11:35 AM, safety0ff wrote:
>> On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>>>
>>> But of course there are many situations out there.
>>
>> Wouldn't it break chained assertion errors?
>
> Once a type in Error's cone gets thrown there is no guarantee of unwinding, hence no guarantee of
> chaining. -- Andrei

For this to have much meaning, at some-point druntime (for all the various compilers) is going to need to be changed to not unwind.  It does, and has all the effects that come from that.  What actually happens tends to trump what the documentation claims it's allowed to not do.  Of course, then you'll find the fun of all the tests (and probably code) that catch AssertError.