Templates - Numeric Types only

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Thu, Aug 6, 2009 at 11:19 PM, Andrei
> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>> Jarrett Billingsley wrote:
>>> On Fri, Aug 7, 2009 at 12:54 AM, Andrei
>>> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>>>> Jarrett Billingsley wrote:
>>>>> On Thu, Aug 6, 2009 at 9:53 PM, Andrei
>>>>> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>>>>>> Jarrett Billingsley wrote:
>>>>>>> On Thu, Aug 6, 2009 at 9:19 PM, Andrei
>>>>>>> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>>>>>>>> Kevin wrote:
>>>>>>>>> Hi,
>>>>>>>>> simple Question:
>>>>>>>>> Is it possible to allow just numeric types in templates?
>>>>>>>>> For example to create a Vector Class like this:
>>>>>>>>>
>>>>>>>>> class Vector(T:"numeric" = float, int size = 4)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Kevin
>>>>>>>> import std.traits;
>>>>>>>>
>>>>>>>> class Vector(T, int size = 4) if (isNumeric!T)
>>>>>>>> {
>>>>>>>>  ...
>>>>>>>> }
>>>>>>> Unfortunately,
>>>>>>>
>>>>>>> struct Vec(T) if(isNumeric!T) {}
>>>>>>> struct Vec(T) {}
>>>>>>> Vec!(int) x; // error
>>>>>>>
>>>>>>> foo.d(14): Error: template instance Vec!(int) matches more than one
>>>>>>> template declaration, Vec(T) if (isNumeric!(T)) and Vec(T)
>>>>>>>
>>>>>>> *sigh*
>>>>>>>
>>>>>>> Wouldn't it be nice.
>>>>>> struct Vec(T) if(isNumeric!T) {}
>>>>>> struct Vec(T) if(!isNumeric!T) {}
>>>>>>
>>>>>> is actually superior because it's more modular; the semantics of the
>>>>>> latter
>>>>>> does not depend on the presence of the former.
>>>>> But the condition of the latter now depends on the condition of the
>>>>> former.  And on the condition of any other 'specializations':
>>>>>
>>>>> struct Vec(T) if(isNumeric!T) {}
>>>>> struct Vec(T) if(isSomeString!T) {}
>>>>> struct Vec(T) if(!isNumeric!T) {} // uhoh
>>>>> Vec!(string) x; // matches two
>>>>>
>>>>> Now the fallback has to be declared as
>>>>>
>>>>> struct Vec(T) if(!isNumeric!T && !isSomeString!T) {}
>>>>>
>>>>> and it gets worse the more you add.
>>>> I know, and I explained why that's arguably better.
>>> So what's the solution?  Integrate template conditions into the
>>> specialization rules?  Use this as a justification for their behavior?
>> Right now the compiler evaluates if clauses early in the matching process,
>> eliminates those that are false, and "forgets" those that are true. It would
>> be possible to make if-clauses an integral part of partial ordering by
>> postulating that an instantiation originating from a matched if clause is
>> more specialized than a template without an if-clause. That would interfere
>> with the other partial ordering rules.
>>
>>>  Or, like so many other features in D, leave it half-specified,
>>> half-useful, and half-implemented because "it got too hard"?
>> Which features of D are you referring to?
> 
> Design by Contract
> "Order of declaration doesn't matter"
> Protection level enforcement of various kinds
> Property syntax
> .stringof
> __traits
> Fixing the linker
> CTFE (in particular memory management or lack thereof)
> immutable (lack of data initialization)
> 
> are the unfinished things that come to mind.
> But I would call those most of those things  90% useful / 90%
> implemented rather than half so.
> Maybe DbC is closer to half than 90%.

Well this assessment I agree with. Note that none of the above "got too 
hard". One of those is compile-time function evaluation; there's such a 
fuzzy boundary between what works and what doesn't, that I must try some 
CTFE code to know whether it works.

Andrei