"Jérôme M. Berger"
jeberger at free.fr
Sun Nov 27 10:36:18 PST 2011
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
> 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.
Debatable, what kind of useful function can be built operating on
the above interface without reference to T (at least through auto)?
> 2. Restrictions can be any Boolean expression, whereas interfaces only
> apply to types.
Strawman! Nothing says that adding compile-time interfaces would
remove boolean restrictions.
> 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.
Strawman again! Everything can be done in straight assembly so in
the end so-called higher-level constructs are redundant.
It should come down to a question of balance between individual
feature simplicity, power, and overall language complexity. Adding a
feature that is simpler and easier to use despite being less
powerful may be a good thing (e.g. "foreach" vs. "while") although
it increases the overall language complexity (additional keywords
and concepts to understand and remember).
mailto:jeberger at free.fr
Jabber: jeberger at jabber.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: OpenPGP digital signature
More information about the Digitalmars-d