Compile-time Interfaces

[Jacob Carlborg]

On 2011-11-27 02:03, Andrei Alexandrescu wrote:
> 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

"auto" cannot be used here. Just like it can't be used in any place 
where there is no implementation of a function.

Seems to me it needs to look something like this:

enum interface Range (T)
{
   void popFront();
   @property bool empty() const;
   @property T front();
}

-- 
/Jacob Carlborg