Is there any plan to support template parameter constraint?

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

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

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

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

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.

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.

"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) { ... }