ref?

[Frits van Bommel]

Andrei Alexandrescu wrote:
> Frits van Bommel wrote:
>> 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?
> 
> Polymorphic. Then of course there's the Finalize!(C) template that takes
> a class C and makes all of its methods final. Compile-time introspection
> is a treasure trove.
> 
>> Would it also delegate template methods?
> 
> Good question. I don't know how template methods could be handled.

Well, one simple way would be to just implement opDot() to take care of 
those :). (Though that would not allow my wrapping suggestion)
Another way would be pressuring Walter into allowing compile-time 
introspection of templates, and providing forwarding aliases or methods 
(possibly wrapping parameters and return types).

>> 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))?
> 
> I don't know. We need more experience to figure that out.
> 
>> 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?
> 
> Segfault :o).

I was hoping you'd answer "They'd use non-nullable parameter types" here ;).