On 7/23/2015 1:08 PM, Dicebot wrote:
> I am not sure how it applies.
D interfaces (defined with the 'interface' keyword) are simple dispatch types,
they don't require an Object. Such interfaces can also have default implementations.
> My point was about the fact that `isInputRange`
> and `InputRangeObject` are the same entities in Rust, simply interpreted
> differently by compiler depending on usage context.
I understand.
> This is important because you normally want to design your application in
terms
> of template constraints and structs to get most out of inlining and
> optimization. However, to define stable ABI for shared libraries, the very
same
> interfaces need to be wrapped in runtime polymorphism.
>
> Closest thing in D would be to define traits as interfaces and use code like
this:
>
> void foo(T)()
> if ( (is(T == struct) || is(T == class))
> && Matches!(T, Interface)
> )
> { }
>
> where `Matches` is a template helper that statically iterates method list of
> interface and looks for matching methods in T.
I don't think the test for struct and class is necessary. It can be just:
void foo(T)() if (Matches!(T, Interface)) { ... }
as opposed to:
void foo(T : Interface)() { ... }
> However, making it built-in feels
> really convenient in Rust:
>
> - considerably less function declaration visual noise
It's less noise, sure, and perhaps we can do some syntactical sugar to improve
that. But I don't think this is a fundamental shortcoming for D as it stands now
(although nobody has written a Matches template, perhaps that should be a priority).
> - much better error messages: trying to use methods of T not defined by a
trait
> will result in compile-time error even without instantiating the template
The error messages will occur at compile time and will be the same if you write
a unit test to instantiate the template. As I wrote earlier, I don't really
understand the need to ship template source code that has never been instantiated.
