Compile-time Interfaces

Timon Gehr timon.gehr at gmx.ch
Sun Nov 27 03:54:48 PST 2011


On 11/27/2011 12:33 PM, Jacob Carlborg wrote:
> On 2011-11-27 02:13, Timon Gehr wrote:
>> 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.
>
> Then what would "T" be?

Any symbol. It is determined by deduction.

> Seems to me it needs to look something like this:
>
> enum interface Range (T)
> {
> void popFront();
> @property bool empty() const;
> @property T front();
> }
>

That is an overly restrictive interface because the element type is fixed.

The interface should be usable like this:
void foo(R : Range)(R input) { /* ... * / }



More information about the Digitalmars-d mailing list