Initialization of std.typecons.RefCounted objects

[monarch_dodra]

On Thursday, 19 July 2012 at 08:14:25 UTC, 
travert at phare.normalesup.org (Christophe Travert) wrote:
> "monarch_dodra" , dans le message (digitalmars.D:172700), a 
> écrit :
>> I think it would be better to "initialize on copy", rather 
>> than default initialize. There are too many cases an empty 
>> array is created, then initialized on the next line, or passed 
>> to something else that does the initialization proper.
>
> Not default-initializing Array has a cost for every legitimate 
> use of an Array.

I'm back pedaling and agreeing 100% actually. Plus it keeps the 
implementation simpler. +1 to you.

> Keeping the adress of the content secret may be a valuable 
> intention,
> but as long as properties and opIndex does not allow to 
> correctly
> forward methods, this is completely broken. Is there even a 
> begining of
> a plan to implement this? I don't see how properties or opIndex 
> could
> safely forward methods that uses references and that we do not 
> control
> without escaping the reference to them. That's not possible 
> until D has
> a complete control of escaping references, which is not planned 
> in the
> near or distant future. Not to mention that having a complete 
> control of
> escaping reference break lots of code anyway, and might 
> considerably
> decrease the need for ref counted utilities like... Array.
>
> Please, at least give me hope that there is light at the end of 
> the
> tunnel.

One of the reason the implementation doesn't let you escape a 
reference is that that reference may become (_unverifiably_) 
invalid. Ranges to Arrays, on the other hand, keep a reference to 
the Array itself, and always* remain valid. (always as long as 
the Array doesn't shrink past the range's boundaries, but in this 
case, at least, the range throws an exception, rather than crash 
the program).

A reference to a dynamic array, on the other hand, will ALWAYS be 
valid 100% of the time, because the original data is never 
actually destroyed (until unreferenced). So it is perfectly safe 
to expose references in an array.

So escaping references from an Array is something _very_ 
dangerous, especially in a language that kind of guarantees it 
won't core dump if you don't manipulate pointers (which could if 
arrays escaped references).

While I get your point, it really feels like a "lose lose" 
situation here: You get stiffed either way...with Array...
...That said, I see no reason for the other containers (SList, 
I'm looking at you), not to expose references.

The way I see it, Array *could* escape references, but then the 
whole class would have to be qualified @unsafe (if such a thing 
existed) or something along these lines.

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

On Thursday, 19 July 2012 at 10:39:56 UTC, Matthias Walter wrote:
> On 07/19/2012 10:14 AM, Christophe Travert wrote:
> I agree here. Additionally my question: Is it possible (at the 
> moment)
> to really do "initialize on copy"? As far as I see it, the only 
> way to
> interact here is to implement 'this(this)' which is called after
> bit-copying and hence cannot access the source of the copy 
> process.

Good point. The answer is no though. A RefCounted (also known as 
SharedPointer in C++) needs to be initialized first if you want 
it aliased.

Allowing such a behavior is possible, but prohibitively expensive.