forcing "@nogc" on class destructors

[ketmar via Digitalmars-d]

On Tue, 20 Jan 2015 21:34:54 +0000
Freddy via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via 
> Digitalmars-d wrote:
> > Hello.
> >
> > as there is no possibility to doing GC allocations in class
> > destructors, wouldn't it be nice to just force "@nogc" 
> > attribute on
> > such dtors?
> >
> > i know, i know, "this will break alot of code". i'm pretty sure 
> > that
> > this will break alot of INVALID code, which better be broken at
> > compile-time anyway.
> >
> > sure, we have alot of code of pre- at nogc era, and alot of code 
> > where
> > authord didn't bother to add attributes at all. so we can 
> > introduce
> > "--force-dtor-nogc" CLI arg and document this change, making it 
> > opt-in
> > for, say, six month and opt-out after that.
> >
> > and i know that D devs (Walter at least) are resistant to 
> > command-line
> > flags that changing compiler behavior. i don't know how to 
> > overcome
> > this. say, by adding "@gc" attribute, which dfix can 
> > automatically add?
> >
> > but i still believe that instead of telling people again and 
> > again that
> > they should not allocate in class destructors, we can use 
> > computer
> > itself to track and stop this behavior.
> >
> > let's see how this proposal will be rejected. will there be 
> > some sane
> > reasons, or only the good old song about "broken code"? make 
> > your bets!
> Not an error, Make it a warning.
alas, attribute violations are errors. turning that into warning means
that compiler needs new flags and new code to determine if that is
"hard restriction" or just "advise". the point of my proposal is that
it can be done painlessly with one or two very simple changes in
compiler code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150120/1754234f/attachment.sig>