RFC on range design for D2

[superdan]

Leandro Lucarella Wrote:

> Andrei Alexandrescu, el  8 de septiembre a las 19:24 me escribiste:
> > 1.5) Allow object ownership but also make the behavior of incorrect code 
> > well-defined so it can be reasoned about, reproduced, and debugged.
> > 
> > That's why I think an Array going out of scope should invoke destructors for its 
> > data, and then obliterate contents with ElementType.init. That way, an 
> > Array!(File) will properly close all files AND put them in a "closed" state. At 
> > the same time, the memory associated with the array will NOT be deallocated, so 
> > a range surviving the array will never crash unrelated code, but instead will 
> > see closed files all over.
> 
> Why is so bad that the program crashes if you do something wrong?

it's not bad. it's good if it crashes. problem is when it don't crash and continues running on oil instead of gas if you see what i mean.

> For how
> long you will have the memory "alive", it will use "regular" GC semantics
> (i.e., when nobody points at it anymore)? In that case, leting the
> programmer leave dangling pointers to data that should be "dead" without
> crashing, wouldn't make easier to introduce memory leaks?

such is the peril of gc. clearly meshing scoping with gc ain't gonna be perfect. but i like the next best thing. scarce resources are deallocated quick. memory stays around for longer. no dangling pointers.