Consistency, Templates, Constructors, and D3

[David Piepgrass]

>> Interestingly, the discussion so far has been all about 
>> syntax, not any
>> significant new features. I'm thinking ... coersion of a class 
>> to any
>> compatible interface (as in Go)?
>
> We already have:
>
> import std.range;
> auto range = ...;
> auto obj = inputRangeObject(range);
> alias ElementType!(typeof(range)) E;
> InputRange!E iface = obj;
> writeln(iface.front);
>
> 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. 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.

I am sometimes amazed by the things the Boost people come up 
with, that support C++03, things that I was "sure" C++03 couldn't 
do, such as lambda/inner functions (see "Boost Lambda Library", 
"Boost.LocalFunction" and "Phoenix"), scope(exit) 
(BOOST_SCOPE_EXIT), and a "typeof" operator (Boost.Typeof). If 
there were 1/4 as many D programmers as C++ ones, I might be 
amazed on a regular basis.

> 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...