forcing "@nogc" on class destructors

[Paolo Invernizzi via Digitalmars-d]

On Thursday, 22 January 2015 at 11:50:55 UTC, Steven 
Schveighoffer wrote:
> On 1/21/15 6:03 PM, Paolo Invernizzi wrote:
>> On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven 
>> Schveighoffer wrote:
>>> On 1/21/15 3:37 AM, Paolo Invernizzi wrote:
>>>> On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven 
>>>> Schveighoffer
>>>> wrote:
>>>>> On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
>>>>> If he does it wrong, it gives him a stack trace on where to 
>>>>> look. What
>>>>> is different here than any other programming error?
>>>>
>>>> Are you suggesting that newcomers should learn D by 
>>>> discovering it day
>>>> by day from stack traces?
>>>
>>> No, I was saying if something causes an exception/error, it 
>>> is a
>>> programming error, and there just isn't any way for a 
>>> compiler to
>>> prevent people from making *any* mistakes.
>>>
>>> But calling sometimes-allocating functions inside a dtor that 
>>> don't
>>> allocate when you call them *that* time shouldn't be banned 
>>> by the
>>> compiler.
>>
>> 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.
>
> -Steve

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.

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".

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... ;-)

--
Paolo