Compile-time Interfaces

[Timon Gehr]

On 11/27/2011 02:03 AM, 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
>

I would solve that similar to this:

enum interface Range {
   private alias T; // could also use 'static' instead of 'private' :o)
   void popFront();
   @property bool empty() const;
   @property T front();
}

Where "T" does not actually contribute to the imposed interface.