On Friday, 11 July 2014 at 05:41:50 UTC, Manu via Digitalmars-d
wrote:
On 11 July 2014 13:45, Walter Bright via Digitalmars-d
<[email protected]> wrote:
On 7/10/2014 7:31 PM, Manu via Digitalmars-d wrote:
So, we allow assert() in nothrow functions, the argument is
that
assert is non-recoverable, so it's distinct from user
exceptions.
I have this in my 'nothrow @nogc' function:
assert(false, "Message " ~ details);
It complains "Error: cannot use operator ~ in @nogc function"
I think it should be allowed to invoke the GC for formatting
error
messages inside of assert statements, just the same as
assert() is
allowed inside of nothrow functions.
Thoughts?
I've thought of allowing "throw new ...", and yours would be
in addition to
that, in @nogc functions, but was waiting to see how this
would play out a
bit first.
I should add, I'm not sure I see that my case should be 'in
addition'.
I think my case should precede since I don't think it's
objectionable,
but I'm really unsure I would get on board with 'throw new ...'
in
@nogc functions. It seems to defeat the purpose to me...?
Why would you want to allow throwing 'new' exceptions?
I also have misgivings about this - while it's the easiest
solution (as I noted in my previous post), it's also antithetical
to @nogc. If one rips out the GC entirely, these exceptions end
up leaking memory which is arguably an even bigger problem,
especially on memory-constrained platforms.
