@nogc

[Philpax via Digitalmars-d]

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
> <digitalmars-d at puremagic.com> 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.