Making AssertError a singleton

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 12 20:45:35 PST 2016


On 12/12/16 11:07 PM, Jonathan M Davis wrote:
> On Monday, 12 December 2016 at 15:51:07 UTC, 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.
>
> I don't know if that would actually work with polymorphic contracts in
> classes.

How do you mean that? Do you have an example in mind?

> It also could be problematic with unit tests - especially unit
> tests that catch AssertErrors (e.g. if someone wants to test the
> contracts).

What kind of problems would it create?

> I also fail to see how this fixes much of anything. If the issue is
> avoiding the GC, it doesn't matter if the program is being killed. If
> the issue is avoiding even linking in the GC, doesn't that mean that
> druntime isn't being used (in which case, doing this in druntime is
> pointless)? So, I don't see how such a change would matter for either
> scenario, and I don't know why else it would be of any value.

Is reducing dependencies for core constructs a good thing?

> And if we fix it so that exceptions don't need the GC (which is arguably
> needed for @nogc to be widely used), then this whole problem goes away
> anyway. So, I'm inclined to argue that we just fix _that_ problem and
> not worry about the fact that assert currently triggers the GC on failure.

I agree the perfect system would fix everything - problem is we don't 
have it yet. The per-thread singleton is a step forward (which at some 
point we should probably make publicly available).


Andrei



More information about the Digitalmars-d mailing list