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
