On 11/26/11 6:40 PM, Kapps wrote:
One of the great things about D is the ability to do so much work at compile-time, including static verification. An example is the amount of constraints available for templates, static ifs, etc. But at some point, it starts getting very problematic to just figure out what something does, and what something can do. An example for this, is ranges. They can be very confusing, and you don't know what they can do without actually going and looking up the exact definition of them. Even then, you have to know that the templated type a function expects is a range. Again, very confusing, and arguably messy. Finally, even now that you know what methods you can call on this mysterious type T, and you see that there's a clause isInputRange!(T) on the method, your IDE still has no clue about any of these things making it impossible to have semi-decent code completion for that type.Which brings in, compile-time interfaces. It seems like a natural thing to include when you have the above tools. Instead of having a method such as: auto DoSomething(T)(T Data) if(isInputRange!(T)) { } You could simply do: auto DoSomething(Range Data) { } where Range is defined as: enum interface Range { void popFront() const; @property bool empty() const; @property auto front(); }
What's "auto" here? This thing alone pretty much destroys the idea; we've considered it very seriously.
Andrei
