forcing "@nogc" on class destructors

[Steven Schveighoffer via Digitalmars-d]

On 1/22/15 8:42 AM, Paolo Invernizzi wrote:
>>> You can't ban them, either now with an annotated @nogc destructor:
>>> SetFunctionAttributes.
>>
>> Right, but the runtime will still catch it if it allocates. I think
>> the correct place to check it is where it's checked now.
>>
>
> I have troubles following your reasoning, so I must have lost something.
>
> - the proposal was to have a default @nogc in the dtor.
> - the rebuttal was that "functions that don't allocate when you call
> them *THAT TIME* shouldn't be banned".
> - I just noticed that also with destructor marked @nogc, if you know and
> trust a @gc function you can use it with the help of traits and casts.
> - the reply was that the runtime will catch it "if it allocate", that I
> don't understand what is related with the notice, or with the original
> proposal.

Missing from this list is that -- if it isn't broke don't fix it :)

I will note that I think if @nogc was the default, I would be in favor 
of keeping it that way. In order to justify a breaking change like this, 
there needs to be a good enough reason. IMO (and really, this is my 
opinion, I'm not the ultimate gatekeeper here) the bar has not been cleared.

> I don't see nothing strange in turning into the default the CT check
> about avoiding GC allocations in destructors, that's the vast majority
> of uses cases, and force an explicit cast/traits if the programmer want
> to mark in the code "hey, I know that using the GC in the DTOR is a bad,
> but trust this cast, in any case If I'm wrong the runtime will signal you".

In the vast majority of cases, nobody adds a dtor, or they use dtors for 
their intended purpose (deallocating non-GC resources) and everything 
works fine. And the runtime catches any slips with an appropriate 
handling (abort instead of corrupt memory).

> Sorry if I feel pedantic in the discussion, but being a not native
> english speaker (and a little in a hurry when writing in the forums) I
> just wanted to be clear in my exposition... ;-)

I understand your opinion, I just don't think it's worth the trouble and 
breaking of code.

-Steve