On 07/19/2012 02:16 PM, Christophe Travert wrote: > "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.
As it seems the issue really should be resolved by making opIndex return by reference and press thumbs hard that something like a 'scope ref' will be implemented? Furthermore, since RefCounted objects do not behave like reference types until initialized, they *must* be initialized before anything else happens and hence I propose to change std.container.Array like Christophe said: Replace 'isInitialized()' checks by assertions and add a method with which the user explicitly initialized the reference counter. Or is there a reasonable alternative? Best regards, Matthias Walter