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
