ref?

[Andrei Alexandrescu]

Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> Well I never seemed to have a problem with it, quite the contrary in
>> fact. Values are easier to reason about because they don't have aliasing
>> and don't foster long-distance interdependencies.
> 
> This.
> 
> When the container is used in a struct, then it must not only be copied,
> but deep-copied when the outer struct is copied.  The same applies when
> the container is used in a class that has a cloning operation defined.
> 
> When the container is used in a class that cannot be cloned or is
> directly placed on the stack, then it doesn't really matter if the
> container has reference or value semantics, since the variable that
> holds the container isn't being copied anyway.
> 
> For those very rare cases where you /want/ the container to be shared,
> you can always use a pointer to the container.

Spot on. My ambitions are actually a tad higher. I want to implement 
containers as by-value structs defining value semantics and the needed 
primitives. Then, using introspection, I want to define a template Class 
that takes a struct and turns it into a class. For example:

struct SomeContainer(T)
{
     ref T opIndex(size_t n) { ... }
}

auto byval = SomeContainer!(int)();
auto javalike = new Class!(SomeContainer!(int));

The type Class!(SomeContainer!(int)) will store a SomeContainer!(int) 
object and will define (by using introspection) a method opIndex of 
which implementation will do what the struct's method does. The net 
effect is as if the programmer sat down with SomeContainer and changed 
"struct" to "class". Of course without the code duplication and the 
maintenance nightmare :o).

Class should work for primitive types, e.g. Class!(int) should do what 
Integer does in Java and so on.


Andrei