What's wrong with D's templates?

Walter Bright newshound1 at digitalmars.com
Tue Dec 22 01:08:41 PST 2009


yigal chripun wrote:
> Walter Bright Wrote:
> 
>> Yigal Chripun wrote:
>>> But that doesn't mean the idea itself isn't valid. Perhaps a
>>> different language with different goals in mind can provide a
>>> much simpler non convoluted implementation and semantics for the
>>> same idea? You've shown in the past that you're willing to break
>>> backward compatibility in the name of progress and experiment
>>> with new ideas. You can make decisions that the C++ committee
>>> will never approve.
>>> 
>>> Doesn't that mean that this is at least worth a shot?
>> I believe that D's template constraint feature fills the bill, it
>> does everything Concepts purported to do, and more, in a simple and
>> easily explained manner, except check the template body against the
>> constraint.
>> 
>> The latter is, in my not-so-humble opinion, a desirable feature but
>> its desirability is overwhelmed by the payment in complexity and 
>> constrictions on the Concepts necessary to make it work.
> 
> could you please expand on what are the main issues with implementing
> that check?

Because the constraint can have any computation in it. So how does one 
verify that all computations in the template body are represented in the 
constraint in the same way?

> I also wonder what's the situation regarding this in
> other languages - C# has constraints IIRC - is the check performed
> there?

I don't know C# constraints.


> IMO cconstraints are neat but they aren't perfect. For one, they need
> to be repeated for each template, it would be very awesome if that
> could be moved to the parameter of the template so instead of:
> 
> template foo(T) if isRange!T ... template bar(T) if isRange!T ...
> 
> you could write something like: struct Range if ... {} template foo(r
> : Range) ... template bar(r : Range) ...
> 
> inside both templates the parameter r satisfies all the constraits of
> Range.
> 
> does that sound reasonable at all?

The template parameter list was already fairly complicated, I thought 
that adding in the constraints would make it impenetrable. Also, the 
parameter list involves the individual parameters, whereas the 
constraint involves any combination of them.

Adding in the constraints to the parameters also has unknown 
consequences for figuring out partial ordering. Partial ordering is 
based on abstract types, whereas constraints are based on actual types.



More information about the Digitalmars-d mailing list