Initialization of std.typecons.RefCounted objects

Christophe Travert travert at phare.normalesup.org
Thu Jul 19 05:16:20 PDT 2012


"monarch_dodra" , dans le message (digitalmars.D:172710), a écrit :
> One of the reason the implementation doesn't let you escape a 
> reference is that that reference may become (_unverifiably_) 
> invalid.

The same applies to a dynamic array: it is undistinguishable from a 
sliced static array. More generally, as long as you allow variables on 
the stack with no escaped reference tracking, you can't ensure 
references remain valid. Even in safe code.

If I want my references to remain valid, I use dynamic array and garbage 
collection. If I use Array, I accept that my references may die. Array 
that protects the validity of their references are awesome. But, IMHO, 
not at that cost.

> ...That said, I see no reason for the other containers (SList, 
> I'm looking at you), not to expose references.

I'm against not exposing reference, but all containers will be 
implemented with custom allocator someday.

> The current work around? Copy-Extract, manipulate, re-insert. 
> Sucks.

IMO, what sucks even more is that arr[0].insert(foo) compiles while it 
has no effect. arr[0] is a R-value, but applying method to R-value is 
allowed. I don't know the state of debates about forbiding to call 
non-const methods on R-values. I think this would break too much code.



More information about the Digitalmars-d mailing list