Collections question

[Steven Schveighoffer via Digitalmars-d]

On 11/27/15 3:14 PM, 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?

How do you prevent the AA behavior? In other words, what happens here:

MyCollection!(int) c1;
auto c2 = c1;
c1 ~= 1;

assert(c2.contains(1)); // pass? fail?

BTW, I third Jonathan's and Timon's suggestion -- go with an external 
factory function. Use IFTI to its fullest!

-Steve