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
