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