Consistency, Templates, Constructors, and D3

[Nick Treleaven]

On 25/08/2012 23:12, David Piepgrass wrote:
>> So maybe we can do:
>>
>> auto implementObject(Interface, T)(T t){...}
>> auto obj = implementObject!(InputRange!E)(range);
>
> Well, my D-fu is too weak to tell whether it's doable. When it comes to
> ranges, the standard library already knows what it's looking for, so I
> expect the wrapping to be straightforward.

I was thinking things like __traits(allMembers, Interface) and other 
__traits might provide enough to do it.

> Even if a template-based
> solution could work at compile-time, run-time (when you want to cast
> some unknown object to a known interface) may be a different story.

My code above does do that - range is unknown, it just has to have 
compatible symbols with Interface's methods. obj is a true Object that 
implements Interface. Continuing the example, you could write:

InputRange!E iface = obj;

Where InputRange!E is a real interface, not a model of one. I.e. you 
could pass it to a non-template function:

void foo(InputRange!E irange){...}
foo(obj);

I'm not sure what's missing (besides an implementation of course ;-)).

 >> Also, it might be nice to have 'canImplement' for template constraints:
 >>
 >> auto foo(T)(T v) if (canImplement!(T, SomeInterface)){...}
 >
 > or 'couldImplement', assuming T doesn't officially declare that it
 > implements the interface...

I was thinking 'can implement' vs. 'does implement'.