Andrei's interface requests

[Robert Jacques]

2784: interface Foo { typedef Bar; }
- confused me for a while, so a clearer description might be nice
-- i.e. clarify that something like 'new I.bar()' is invalid.
- seems only to be useful as part of the other contract-like interface  
enhancements
-- Like 2786 & 2785 below, this creates a difference between normal  
interface members and typedefs, which I don't like.

2785: interface Foo{ extern void bar(int, Foo, double);
- I like the concept of extern functions in this concept, though it does  
rise questions of what scopes/modules are used for match searching.
- The use of Foo to mean the class name seems like the wrong keyword.
-- What if I truly wanted a function that took a Foo?
-- This makes these function definitions behave differently than  
definitions outside the interface. Perhaps 'typeof(this)'
- Like 2786 below, this creates a difference between normal interface  
members and externs, which I don't like.

2786: Interfaces should be able to require constructors
- Seems like a decent idea.
- But, this creates a difference between normal interface members and the  
constructor, which I don't like:
-- the implementors                    have a ___     // constructor
-- the implementors and the interface  have a ___     // everything else

2050: Interfaces with static/final methods with method bodies
- I like the idea of defining that an interface implementor should have  
static or final methods.
- However, there seem to be some major composability issues, with  
implementing two interfaces with identical final / static methods.
-- i.e. this is the classic diamond problem of multiple inheritance, just  
with functions instead of functions and data.
-- This also applies to overloading an interface's static or final method.  
Is it possible? What happens when the class is accessed through the  
interface?
- How is this superior to the current interface + mixin approach?
-- Or an mixin-able interface approach? i.e. mixin myInterface; // Add  
myInterface's method bodies to a class

Regarding Interfaces and Concepts
Though struct interfaces, etc would be very nice, couldn't compile time  
reflection be used to create a Duck/Concept-type template constraint:
template void foo(T)(T x, T y)
     if( isDuck!(T,InputRange) ) {...}

Summary
Essentially all these enhancements would create a major difference between  
an interface and its implementor, which I think is a Bad Idea(tm). And the  
problem its trying to solve (i.e. c++ Concepts) is probably better solved  
with a general compile-time reflection template, than by altering  
interfaces.