Compile-time Interfaces

[Jacob Carlborg]

On 2011-11-27 16:47, Andrei Alexandrescu wrote:
> On 11/27/11 5:36 AM, Jacob Carlborg wrote:
>> "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();
>> }
>
> That seems helpful, but it doesn't lead on a good path, for several
> reasons.
>
> 1. Right now we have "function applies to any type R that is a range".
> With the other approach, there'd be "function applies to any type T such
> that the given type R is a Range!T". That roundabout approach is likely
> to scale poorly to more complex cases. It's arguably inferior because
> often the range-ness is of interest, not naming T.

I was missinterpreting the isInputRange template.

> 2. Restrictions can be any Boolean expression, whereas interfaces only
> apply to types.
>
> 3. In an interface-based approach, everything must be named; there are
> no optional properties such as hasLength or isInfinite. That could, of
> course, be added as restricted templates, which means interfaces must
> coexist with restricted templates, a more powerful feature. So in the
> end interfaces are redundant.

For the simpler cases an interface is easier to reason about. But yes, 
template constraints are more powerful.

-- 
/Jacob Carlborg