Making AssertError a singleton

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 13 December 2016 at 22:47:55 UTC, Andrei Alexandrescu 
wrote:
> On 12/13/2016 05:05 PM, Jonathan M Davis wrote:
> Recall that all AssertError instances are equivalent up to file 
> and line.

They also have a message. AssertErrors aren't any more the same 
as each other than any other exception type.

> Would be quite cool if all failed assertions showed the same 
> file and line, eh? :o)

LOL. Not so much, no.

> I'm actually of a mind to push this in the language 
> specification - Error objects are not guaranteed to be 
> distinct. Errors already have a number of concessions and 
> shouldn't be used naively.

I might agree if we weren't talking about AssertErrors, but 
assertions are used in contracts and unit tests where they do not 
kill the program and potentially need mupltiple instances to work 
properly with anyone who wants to show all failures rather than 
just one per module.

Also, aside from the fact that nothrow let's you throw Errors, 
there's really nothing special about Errors at this point. 
nothrow does have the side effect that you don't always get full 
stack cleanup with Errors (and Walter would like that to be the 
case for cleanup with Errors in general), but the Error objects 
themselves are not special, and not having full cleanup with 
AssertErrors with contracts and unit tests would be a big problem 
for some people. There are people who test their contracts and 
other Errors with unit tests to make sure that they fail when and 
how they're supposed to. Either skipping the cleanup in that case 
or making Errors singletons would break such code, and I don't 
know how anyone could test their contracts if your proposal went 
through.

> Right now I don't know what to do to make all exceptions not 
> use GC.

Wouldn't the reference counting solution that you and Walter 
agreed needed to be done make it possible to fix it so that 
exceptions don't have to use the GC?

> I do know what to do to avoid using the GC in assert, and in my 
> opinion at a negligible cost in amenities. We can't afford to 
> refuse to take a step just because the journey is long.

Well, this seems to only be of benefit to the folks trying to use 
betterC, and it's going to cause problems for D programmers that 
don't care about betterC at all. Given the kind of restrictions 
and feature-reduction that the folks using betterC are looking 
for, it seems to me to make a lot more sense to take advantage of 
version statements  so that the betterC folks can have a stripped 
down build of druntime without negatively impacting D's features 
for the rest of us.

- Jonatan M Davis