Collections question

[bitwise via Digitalmars-d]

On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu 
wrote:
> There's this oddity of built-in hash tables: a reference to a 
> non-empty hash table can be copied and then both references 
> refer to the same hash table object. However, if the hash table 
> is null, copying the reference won't track the same object 
> later on.
>
> Fast-forward to general collections. If we want to support 
> things like reference containers, clearly that oddity must be 
> addressed. There are two typical approaches:
>
> 1. Factory function:
>
> struct MyCollection(T)
> {
>     static MyCollection make(U...)(auto ref U args);
>     ...
> }
>
> So then client code is:
>
> auto c1 = MyCollection!(int).make(1, 2, 3);
> auto c2 = MyCollection!(int).make();
> auto c3 = c2; // refers to the same collection as c2
>
> 2. The opCall trick:
>
> struct MyCollection(T)
> {
>     static MyCollection opCall(U...)(auto ref U args);
>     ...
> }
>
> with the client code:
>
> auto c1 = MyCollection!(int)(1, 2, 3);
> auto c2 = MyCollection!(int)();
> auto c3 = c2; // refers to the same collection as c2
>
> There's some experience in various libraries with both 
> approaches. Which would you prefer?
>
>
> Andrei

Classes/real-ref-types dont act as you're describing, so why 
should these fake struct wrapper ref things act this way? This 
will likely achieve the exact opposite of what you're aiming for, 
by making something that's supposed to act like a reference type 
have different behaviour from D's built in ref types.

     Bit