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
