Compile-time Interfaces
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sun Nov 27 12:14:39 PST 2011
On 11/27/11 12:36 PM, "Jérôme M. Berger" wrote:
>> 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)?
It is simpler syntactically and semantically to say "function works for
any range R" and then optionally use ElementType!R, than to compulsively
express both in one shot.
>> 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.
What I meant to say was that since we need restricted templates anyway
and compile-time interfaces would be a redundant addition to the
language, we may as well question their usefulness.
>> 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!
This is not helping the exchange.
> Everything can be done in straight assembly so in
> the end so-called higher-level constructs are redundant.
This reduction of a reasonable argument doesn't, either.
> 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).
Of course. But compile-time interfaces would need to stand on their own.
We can't add such just because foreach makes things easier than while.
Instead of ridiculing my arguments or engaging in fruitless comparisons,
you may as well come with valid arguments in favor of compile-time
interfaces.
Thanks,
Andrei
More information about the Digitalmars-d
mailing list