www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Templates - Numeric Types only

reply Kevin <s.keptiker web.de> writes:
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
Aug 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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) { ... } Andrei
Aug 06 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Aug 6, 2009 at 9:19 PM, Andrei
Alexandrescu<SeeWebsiteForEmail 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" =3D float, int size =3D 4)

 Thanks,
 Kevin

import std.traits; class Vector(T, int size =3D 4) if (isNumeric!T) { =A0 =A0... }

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.
Aug 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:19 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail 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

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. Andrei
Aug 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:53 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:19 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail 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

class Vector(T, int size = 4) if (isNumeric!T) { ... }

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) {} 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. Andrei
Aug 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Fri, Aug 7, 2009 at 12:54 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:53 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:19 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail 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

class Vector(T, int size = 4) if (isNumeric!T) { ... }

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) {} is actually superior because it's more modular; the semantics of the latter does not depend on the presence of the former.

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.


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? Andrei
Aug 06 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
  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%. --bb

Others that come to mind: DIPs shared debugger support arrays
Aug 07 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 DIPs
 shared
 debugger support
 arrays

You'll be soon surprised regarding literally all of the above. But I don't want to speak again on Walter's behalf :o). Andrei
Aug 07 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Aug 6, 2009 at 11:19 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Fri, Aug 7, 2009 at 12:54 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:53 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:19 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail 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

class Vector(T, int size = 4) if (isNumeric!T) { ... }

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) {} is actually superior because it's more modular; the semantics of the latter does not depend on the presence of the former.

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.


specialization rules? Use this as a justification for their behavior?

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"?


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
Aug 07 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Aug 6, 2009 at 9:53 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:19 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail 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" =3D float, int size =3D 4)

 Thanks,
 Kevin

import std.traits; class Vector(T, int size =3D 4) if (isNumeric!T) { =A0 ... }

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 latt=

 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.
Aug 06 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Aug 7, 2009 at 12:54 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:53 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:19 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail 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" =3D float, int size =3D 4)

 Thanks,
 Kevin

import std.traits; class Vector(T, int size =3D 4) if (isNumeric!T) { =A0... }

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. =A0And 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? Or, like so many other features in D, leave it half-specified, half-useful, and half-implemented because "it got too hard"?
Aug 06 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Aug 6, 2009 at 11:19 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Fri, Aug 7, 2009 at 12:54 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:53 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Jarrett Billingsley wrote:
 On Thu, Aug 6, 2009 at 9:19 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail 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" =3D float, int size =3D 4)

 Thanks,
 Kevin

import std.traits; class Vector(T, int size =3D 4) if (isNumeric!T) { =A0... }

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. =A0And 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? =A0Integrate template conditions into the specialization rules? =A0Use 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 wo=

 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 interfe=

 with the other partial ordering rules.

 =A0Or, 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%. --bb
Aug 07 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Aug 7, 2009 at 6:16 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 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.

I was referring specifically to the well-known issue with heavy CTFE code not freeing temp strings and such that are allocated by the compiler. For some CTFE code this causes the compiler to leak so much memory that the compilation slows to a crawl. To me that certainly looks like a case of "got too hard (relative to the benefit it would provide)". --bb
Aug 07 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Aug 7, 2009 at 9:16 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 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 =A090% 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".

I've been told *by Walter* that solving forward reference issues are difficult to solve for any real benefit. That sounds like "got too hard" to me.
Aug 07 2009