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.
signature.asc
Description: PGP signature
