ref?

[Frits van Bommel]

Andrei Alexandrescu wrote:
> 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.

An interesting idea. Would Class!(T) allow polymorphism, or would all 
methods be implicitly final?
Would it also delegate template methods?

And what would happen to any T methods accepting or returning T? Would 
they keep returning T or would they be replaced by Class!(T)? Or perhaps 
both, through overloading?
Same question for types derived from T (e.g. Nullable!(T), or 
SomeContainer!(T))?

For instance in the case of a container it would be nice to allow 
Class!(LinkedList!(T)).splice!(Class!(LinkedList!(T)) other) if there's 
a LinkedList!(T).splice(LinkedList(T) other).

If such unwrapping were done, how would such methods react if the 
Class!(LinkedList!(T)) passed into slice() were null?