www.digitalmars.com         C & C++   DMDScript  

D - Template Constraint

reply Ben Y. <Ben_member pathlink.com> writes:
Is there any plan to support template parameter constraint?
Oct 24 2003
parent reply Andy Friesen <andy ikagames.com> writes:
Ben Y. wrote:


 Is there any plan to support template parameter constraint?


You could effect a constraint by specializing the template, and putting 
a static assert(false) in the body.

  -- andy
Oct 24 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
That static assert scheme sounds pretty lame.

I think constraints should be the default.  It is a very rare case (unsorted
container classes, or transparent data movers) that you don't care what your
template gets instantiated on.  Most of the time a template is designed for
a type with certain functionality, certain operators, which is nicely
expressed by saying the type must derive from some class, struct, or
interface.  It gets really powerful when you have some core type classes
such as Numeric, Integral, Real, Comparable, Ordered, Copyable, Pointer,
Logical, BitOps, etc. that the basic types derive from or somehow provide.


Copyable  (=)
        Comparable  (==, !=)
                Ordered  (<, <=, >, >=)
                        Enum  (--, ++)
                                Logical   (&&, ||, !)
                                Pointer  (->, *)
                        Numeric  (+,-,*)
                                Integral  (\,%)
                                        BitOps   (&,|,^,~)
                                Real    (/)

Note that the above are all abstract types.  It should also have multiple
inheritance, since for instance Integral should also derive off Enum, but
not everything derived off Enum should be Numeric.  We might also want to
constrain a template to something derived off some user-defined type, or
maybe to have the same interface as, say, int.  In that case it would be
*really* nice to be able to do this:

struct MyInt : int
{
    void CustomPrettyPrint();
};

Sean

"Andy Friesen" <andy ikagames.com> wrote in message
news:bnc85n$30ci$1 digitaldaemon.com...

 Ben Y. wrote:


 Is there any plan to support template parameter constraint?


 You could effect a constraint by specializing the template, and putting
 a static assert(false) in the body.

   -- andy
Oct 25 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 That static assert scheme sounds pretty lame.


Agreed


 I think constraints should be the default.  It is a very rare case


(unsorted

 container classes, or transparent data movers) that you don't care what


your

 template gets instantiated on.  Most of the time a template is designed


for

 a type with certain functionality, certain operators, which is nicely
 expressed by saying the type must derive from some class, struct, or
 interface.  It gets really powerful when you have some core type classes
 such as Numeric, Integral, Real, Comparable, Ordered, Copyable, Pointer,
 Logical, BitOps, etc. that the basic types derive from or somehow provide.


 Copyable  (=)
         Comparable  (==, !=)
                 Ordered  (<, <=, >, >=)
                         Enum  (--, ++)
                                 Logical   (&&, ||, !)
                                 Pointer  (->, *)
                         Numeric  (+,-,*)
                                 Integral  (\,%)
                                         BitOps   (&,|,^,~)
                                 Real    (/)


This could be great! Imagine if D was the first (usable) language to support
meta programming. Why not have a compile-time association with all types,
fundamental or user-defined?


 Note that the above are all abstract types.  It should also have multiple
 inheritance, since for instance Integral should also derive off Enum, but
 not everything derived off Enum should be Numeric.  We might also want to
 constrain a template to something derived off some user-defined type, or
 maybe to have the same interface as, say, int.  In that case it would be
 *really* nice to be able to do this:

 struct MyInt : int
 {
     void CustomPrettyPrint();
 };

 Sean

 "Andy Friesen" <andy ikagames.com> wrote in message
 news:bnc85n$30ci$1 digitaldaemon.com...

 Ben Y. wrote:


 Is there any plan to support template parameter constraint?


 You could effect a constraint by specializing the template, and putting
 a static assert(false) in the body.

   -- andy
Oct 25 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
We should definitely be able to build our own types.  Once you have
program-controlled compile-time code generation, you can do amazing things
in a language.

So far we've played with mostly genericism at compile time because
interpreted languages were too slow.  That is about to change.

Anyway yeah, I want to be able to get as close to the metal as possible, to
the point of making your own kinds of ints and such.  Why not integrate it?
Unifying the type system is A Good Thing.  Really, what is an int except a
programmer's representation of a region of memory.  That representation goes
thru several translation layers anyway between you and the machine itself
(the transistors).  So if I want to add a translation layer, I don't want to
pay for it at the low end, near the machine, but rather up on my end, in the
language or thought domain.  Something that clears things up and totally
hides what is below.

What is a language really but a universal translator.  It is a layer.

Walter, what are your licensing terms for using DMC++ as a part of another
actual product?  As a tool for making dynamic programs?  ;)  For a D program
that runs its own compiler and executes the results?

Sean

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bneq15$1jju$1 digitaldaemon.com...

 That static assert scheme sounds pretty lame.


 Agreed


 I think constraints should be the default.  It is a very rare case


 (unsorted

 container classes, or transparent data movers) that you don't care what


 your

 template gets instantiated on.  Most of the time a template is designed


 for

 a type with certain functionality, certain operators, which is nicely
 expressed by saying the type must derive from some class, struct, or
 interface.  It gets really powerful when you have some core type classes
 such as Numeric, Integral, Real, Comparable, Ordered, Copyable, Pointer,
 Logical, BitOps, etc. that the basic types derive from or somehow




provide.

 Copyable  (=)
         Comparable  (==, !=)
                 Ordered  (<, <=, >, >=)
                         Enum  (--, ++)
                                 Logical   (&&, ||, !)
                                 Pointer  (->, *)
                         Numeric  (+,-,*)
                                 Integral  (\,%)
                                         BitOps   (&,|,^,~)
                                 Real    (/)


 This could be great! Imagine if D was the first (usable) language to


support

 meta programming. Why not have a compile-time association with all types,
 fundamental or user-defined?


 Note that the above are all abstract types.  It should also have




multiple

 inheritance, since for instance Integral should also derive off Enum,




but

 not everything derived off Enum should be Numeric.  We might also want




to

 constrain a template to something derived off some user-defined type, or
 maybe to have the same interface as, say, int.  In that case it would be
 *really* nice to be able to do this:

 struct MyInt : int
 {
     void CustomPrettyPrint();
 };

 Sean

 "Andy Friesen" <andy ikagames.com> wrote in message
 news:bnc85n$30ci$1 digitaldaemon.com...

 Ben Y. wrote:


 Is there any plan to support template parameter constraint?


 You could effect a constraint by specializing the template, and






putting

 a static assert(false) in the body.

   -- andy
Oct 26 2003
prev sibling parent reply Ben Y. <Ben_member pathlink.com> writes:
Constraint based on subtyping relationship could entail unnecessary overhead on
performance. 
Say, to use MyTemplate, the type has to derive from MyInterface. 

For types not designed to implement MyInterface but actually does have the
required semantics, adapter has to be built.

And normally an adapter will introduce one more level of runtime indirection.

Ideally, a constraint served as a "concept" in the C++ "concept-model" notion.
And a concept is better not restricted to a dynamically dispatched interface.

It would be nice to introduce a seperate scheme to represent "concept" without
necessarily resort to dynamic dispatch.


In short, concept describes static semantics only, while interfaces and types
specify both static and dynamic semantics.
Oct 27 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
So don't use constraints in those cases!

Constraints help you find bugs at compile time, but screening out crap that
doesn't have the right interface.  If it doesn't have the right interface,
you'd have to build an adapter anyway because the template is set up to use
the "implied" interface constraint anyway, but in that case the compiler
doesn't have any hint as to what the "implied" interface is, so it has to
guess, and recompile each instantiation to see if the new type will "fit".

It really doesn't have much to do with runtime performance at all.  It's
more like a contract.  It won't necessitate dynamic dispatch.  The compiler
still knows the actual type on instantiation.

Sean


"Ben Y." <Ben_member pathlink.com> wrote in message
news:bnk3kp$g0p$1 digitaldaemon.com...

 Constraint based on subtyping relationship could entail unnecessary


overhead on

 performance.
 Say, to use MyTemplate, the type has to derive from MyInterface.

 For types not designed to implement MyInterface but actually does have the
 required semantics, adapter has to be built.

 And normally an adapter will introduce one more level of runtime


indirection.

 Ideally, a constraint served as a "concept" in the C++ "concept-model"


notion.

 And a concept is better not restricted to a dynamically dispatched


interface.

 It would be nice to introduce a seperate scheme to represent "concept"


without

 necessarily resort to dynamic dispatch.


 In short, concept describes static semantics only, while interfaces and


types

 specify both static and dynamic semantics.
Oct 28 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Ben Y." <Ben_member pathlink.com> wrote in message
news:bnk3kp$g0p$1 digitaldaemon.com...

 Constraint based on subtyping relationship could entail unnecessary


overhead on

 performance.
 Say, to use MyTemplate, the type has to derive from MyInterface.


Already existing in D:

    template Foo(T : MyInterface) { ... }
Dec 19 2003