Compile-time Interfaces

[Andrei Alexandrescu]

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