Making AssertError a singleton

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 13 December 2016 at 04:45:35 UTC, Andrei Alexandrescu 
wrote:
> 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?

I mean that with virtual functions, in contracts get ||ed and out 
contracts get &&ed. Since that involves assertions, unless the 
compiler is doing something special there with assert, that 
involves throwing multiple AssertErrors and catching them. 
Depending on how that's implemented, having a singleton for 
AssertError would break that. If so, I expect that it's fixable, 
but simply turning AssertError into a singleton without verifying 
how that would affects contracts on virtual functions seems like 
a bad idea.

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

Well, if anyone is catching AssertErrors in unit tests, then 
they'll no longer be getting multiple of them. For some stuff, it 
wouldn't matter, but for other stuff it would break it. For 
instance, while the default test runner stops on the first 
failure in a unittest block, others are going to run them all and 
then print out the failures, and if AssertError is a singelton, 
then all of the AssertErrors that were stored to print at the end 
would then be the same AssertError and would print the same 
thing, defeating the purpose of the alternate test runner.

> Is reducing dependencies for core constructs a good thing?

It is when it reduces functionality, which this does. It puts 
unnecessary restrictions on AssertError which are of zero benefit 
for the vast majority of D programs.

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

We _need_ to fix the fact that exceptions require the GC, or 
@nogc is utterly useless for large portions of D code simply 
because of the exceptions, which will make it much harder to use 
D without the GC. If we fix it so that exceptions don't need the 
GC, then this problem goes away, and these changes are just an 
unnecessary complication in druntime.

- Jonathan M Davis