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.
