On Tue, 20 Jan 2015 20:25:13 +0000
Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 20 January 2015 at 18:25:42 UTC, ketmar via 
> Digitalmars-d wrote:
> > how likely this to be changed? is there *any* chances of that 
> > in 2015?
> > 2016? and why we can't just remove that restriction when new GC 
> > will be
> > implemented? removing the "@nogc" requirement on class dtors 
> > will break
> > *nothing* *at* *all*. yet adding it now, while we don't have 
> > that new
> > GC, will prevent alot of bugs that can slip in crack.
> >
> > btw, you won the prize of not talking about "broken code"! 
> > sadly, i
> > forgot to setup the prizes... anyway, thanks for sane argument.
> 
> Is it that subtle of a bug? Your program crashes once, you go on 
> the forums and find the answer, and then you know never to do it 
> again.
and then you will inevitably do it again and again, 'cause compiler is
silent about allocations in destructor. and you may accidentally call
functions from another libraries which allocating. and then it can be
hidden behind some `if`'s, so it will not crash for you, but will crash
for someone other.

and all that mess can be avoided just by enforcing the one simple rule,
which compiler is perfectly able to check.

> Someone who wants to avoid hidden allocations in a 
> destructor will mark all their class destructors @nogc anyway
that if he KNOWS about hidden traps of allocating in class destructors.
this way we can stop doing any checking at all, 'cause someone who
knows what he wants will write the code to check what he wants anyway.

Attachment: signature.asc
Description: PGP signature

Reply via email to