Bill Baxter wrote:
On Thu, Aug 6, 2009 at 11:19 PM, Andrei
Alexandrescu<[email protected]> wrote:
Jarrett Billingsley wrote:
On Fri, Aug 7, 2009 at 12:54 AM, Andrei
Alexandrescu<[email protected]> wrote:
Jarrett Billingsley wrote:
On Thu, Aug 6, 2009 at 9:53 PM, Andrei
Alexandrescu<[email protected]> wrote:
Jarrett Billingsley wrote:
On Thu, Aug 6, 2009 at 9:19 PM, Andrei
Alexandrescu<[email protected]> 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
