I've been meaning to get some concrete ideas on the table, with respect to templates, for quite some time, but I haven't had much of a chance to sort out my thoughts. I figured it was about time I sat down and hammered out a few concrete examples that will illustrate what I'm looking for.

I use templates primarily for collection classes. I know you can do other things with them, but I haven't ever felt much need, myself. So, my suggestions come primarily from a collections-class oriented perspective. Someone other than me will have to provide the perspective for any of those other uses for templates.

The crux of these suggestions is that we should be able to treat classes defined within a template (and instantiated elsewhere in the code) just like ordinary classes. For example:

***************************************************
class myClass {

	instance TLinkedList(char[]).LinkedList myListClass;
	instance TLinkedList(char[]).ListNode myNodeClass;

	public myListClass thisList;
	public myListClass thatList;

	public myListClass makeList() {
		myListClass myList = new myListClass();
		return myList;
	}

	public myNodeClass getNode(myListClass myList, int index) {
		return myList.getNode(nodeNumber);
	}
}
***************************************************

In this example, once I've instantiated "myListClass" and "myNodeClass" as instances, I can forget that they ever came from a template, and from that point on I can treat them just like ordinary classes, passing them into funcitons, returning them from functions, and using the "new" keyword to create new objects from them.

I'd also like to be able to inherit from a class defined inside of a template. As an example, take a look at the following code:

in baseTemplate.d:
***************************************************
module baseTemplate.d;
template baseTemplate(T) {
	class baseClass {
		T[10] objectArray;
	}
}

in derivedClass.d
***************************************************
import baseTemplate.d;
instance baseTemplate(int).baseClass myBaseClass;
class derivedClass: myBaseClass {
	public int getFirstMember() {
		return objectArray[0];
	}
}
***************************************************

Inheriting from a class that was defined inside of a template, and instantiated before the class declaration, would make my life so much simpler. And, what's more, I don't see why this type of stuff can't be checked at compile-time. Arguably, compile-time constraints on template instantiations might take away a little bit of the flexibility of the templating system, but most of the time I don't need that flexibility. Most of the time, I'm happy setting in stone the type that gets passed into the template at compile time, preventing the computational overhead of runtime template-handling. Perhaps it would also be nice to have the compiler in-line template definitions when it determines that it's safe to do so, just like it now inlines functions when it can ensure that there's no recursion.

Anyhow, that's all I've got for now. I'll probably have some more template ideas within the next few days (especially if I'm prompted by some good discussion on this thread), but I readily admit that I'm only covering a very small part of the whole templating universe. And, like I said, someone else will have to throw their ideas on the table for that.

--Benji Smith

Does anybody else have an opinion about my template wishlist?

--Benji Smith

On Wed, 13 Aug 2003 08:16:18 -0600, Benji Smith <dlanguage@xxagg.com> wrote:

>I've been meaning to get some concrete ideas on the table, with respect to templates, for quite some time, but I haven't had much of a chance to sort out my thoughts. I figured it was about time I sat down and hammered out a few concrete examples that will illustrate what I'm looking for.
>
>I use templates primarily for collection classes. I know you can do other things with them, but I haven't ever felt much need, myself. So, my suggestions come primarily from a collections-class oriented perspective. Someone other than me will have to provide the perspective for any of those other uses for templates.
>
>The crux of these suggestions is that we should be able to treat classes defined within a template (and instantiated elsewhere in the code) just like ordinary classes. For example:
>
>***************************************************
>class myClass {
>
>	instance TLinkedList(char[]).LinkedList myListClass;
>	instance TLinkedList(char[]).ListNode myNodeClass;
>
>	public myListClass thisList;
>	public myListClass thatList;
>
>	public myListClass makeList() {
>		myListClass myList = new myListClass();
>		return myList;
>	}
>
>	public myNodeClass getNode(myListClass myList, int index) {
>		return myList.getNode(nodeNumber);
>	}
>}
>***************************************************
>
>In this example, once I've instantiated "myListClass" and "myNodeClass" as instances, I can forget that they ever came from a template, and from that point on I can treat them just like ordinary classes, passing them into funcitons, returning them from functions, and using the "new" keyword to create new objects from them.
>
>I'd also like to be able to inherit from a class defined inside of a template. As an example, take a look at the following code:
>
>in baseTemplate.d:
>***************************************************
>module baseTemplate.d;
>template baseTemplate(T) {
>	class baseClass {
>		T[10] objectArray;
>	}
>}
>
>in derivedClass.d
>***************************************************
>import baseTemplate.d;
>instance baseTemplate(int).baseClass myBaseClass;
>class derivedClass: myBaseClass {
>	public int getFirstMember() {
>		return objectArray[0];
>	}
>}
>***************************************************
>
>Inheriting from a class that was defined inside of a template, and instantiated before the class declaration, would make my life so much simpler. And, what's more, I don't see why this type of stuff can't be checked at compile-time. Arguably, compile-time constraints on template instantiations might take away a little bit of the flexibility of the templating system, but most of the time I don't need that flexibility. Most of the time, I'm happy setting in stone the type that gets passed into the template at compile time, preventing the computational overhead of runtime template-handling. Perhaps it would also be nice to have the compiler in-line template definitions when it determines that it's safe to do so, just like it now inlines functions when it can ensure that there's no recursion.
>
>Anyhow, that's all I've got for now. I'll probably have some more template ideas within the next few days (especially if I'm prompted by some good discussion on this thread), but I readily admit that I'm only covering a very small part of the whole templating universe. And, like I said, someone else will have to throw their ideas on the table for that.
>
>--Benji Smith

It seems you're requesting some really basic template behavior, and if it's not already in D, then I'm surprised and alarmed.

Sean

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:522qjvo36o9m11808me54qms0brr9anhr9@4ax.com...
> Does anybody else have an opinion about my template wishlist?
>
> --Benji Smith
>
> On Wed, 13 Aug 2003 08:16:18 -0600, Benji Smith <dlanguage@xxagg.com> wrote:
>
> >I've been meaning to get some concrete ideas on the table, with respect to templates, for quite some time, but I haven't had much of a chance to sort out my thoughts. I figured it was about time I sat down and hammered out a few concrete examples that will illustrate what I'm looking for.
> >
> >I use templates primarily for collection classes. I know you can do other things with them, but I haven't ever felt much need, myself. So, my suggestions come primarily from a collections-class oriented perspective. Someone other than me will have to provide the perspective for any of those other uses for templates.
> >
> >The crux of these suggestions is that we should be able to treat classes defined within a template (and instantiated elsewhere in the code) just like ordinary classes. For example:
> >
> >***************************************************
> >class myClass {
> >
> > instance TLinkedList(char[]).LinkedList myListClass;
> > instance TLinkedList(char[]).ListNode myNodeClass;
> >
> > public myListClass thisList;
> > public myListClass thatList;
> >
> > public myListClass makeList() {
> > myListClass myList = new myListClass();
> > return myList;
> > }
> >
> > public myNodeClass getNode(myListClass myList, int index) {
> > return myList.getNode(nodeNumber);
> > }
> >}
> >***************************************************
> >
> >In this example, once I've instantiated "myListClass" and "myNodeClass" as instances, I can forget that they ever came from a template, and from that point on I can treat them just like ordinary classes, passing them into funcitons, returning them from functions, and using the "new" keyword to create new objects from them.
> >
> >I'd also like to be able to inherit from a class defined inside of a template. As an example, take a look at the following code:
> >
> >in baseTemplate.d:
> >***************************************************
> >module baseTemplate.d;
> >template baseTemplate(T) {
> > class baseClass {
> > T[10] objectArray;
> > }
> >}
> >
> >in derivedClass.d
> >***************************************************
> >import baseTemplate.d;
> >instance baseTemplate(int).baseClass myBaseClass;
> >class derivedClass: myBaseClass {
> > public int getFirstMember() {
> > return objectArray[0];
> > }
> >}
> >***************************************************
> >
> >Inheriting from a class that was defined inside of a template, and instantiated before the class declaration, would make my life so much simpler. And, what's more, I don't see why this type of stuff can't be checked at compile-time. Arguably, compile-time constraints on template instantiations might take away a little bit of the flexibility of the templating system, but most of the time I don't need that flexibility. Most of the time, I'm happy setting in stone the type that gets passed into the template at compile time, preventing the computational overhead of runtime template-handling. Perhaps it would also be nice to have the compiler in-line template definitions when it determines that it's safe to do so, just like it now inlines functions when it can ensure that there's no recursion.
> >
> >Anyhow, that's all I've got for now. I'll probably have some more template ideas within the next few days (especially if I'm prompted by some good discussion on this thread), but I readily admit that I'm only covering a very small part of the whole templating universe. And, like I said, someone else will have to throw their ideas on the table for that.
> >
> >--Benji Smith
>

> Does anybody else have an opinion about my template wishlist?
>
> --Benji Smith
>
> On Wed, 13 Aug 2003 08:16:18 -0600, Benji Smith <dlanguage@xxagg.com> wrote:
>
> >I've been meaning to get some concrete ideas on the table, with respect to templates, for quite some time, but I haven't had much of a chance to sort out my thoughts. I figured it was about time I sat down and hammered out a few concrete examples that will illustrate what I'm looking for.
> >
> >I use templates primarily for collection classes. I know you can do other things with them, but I haven't ever felt much need, myself. So, my suggestions come primarily from a collections-class oriented perspective. Someone other than me will have to provide the perspective for any of those other uses for templates.
> >

Assuming that D template are as powerfull as those in C++, what I would like is:

- The ability to specify multiple bases (in C++, it is usefull for ATL,
WTL...). I think this is agood uses of MI where someone can have
a template class where its behavior is defined from which base it derives.

- The possibility to uses function like syntax for metaprogramming functions. We could have something like (I uses a syntax similar to C++ since this is what I know):

template <typename T>
bool metafunction is_positive(T value) { return value >= 0; }

and it would be possible to uses those function everywhere constant expressions are required (in particular for integral type template parameters (I hope this is supported in D).

In those function, we would be restricted to call other meta function or similar thing that the compiler can do at compile time.

In C++, we have to write lot of code to do simple metaprogramming since we typically have to define template classes with integral type parameters and have some specialisations....

And it C++, it would be very hard to support more than one type
for such metafunction. For ex. if we want that for a given user type
is_positive always returns true, we would just need one specialisation
for that type... and not a few mores or less complex classes as in C++

Walter can either confirm or deny it, but I'm not aware of these capabilities in D templates. I don't think you can pass around a template-instantiated object the same way you can pass around a regular object. And I don't think that you can create a class that inherits from a template-instantiated class. Am I wrong?

If it's possible to do these things (see my original post at the top of this thread), the syntax isn't documented anywhere that I'm aware of.

And, yeah, if you can't do these things, we all deserve to be alarmed.

--Benji Smith

On Fri, 15 Aug 2003 10:12:49 -0700, "Sean L. Palmer" <palmer.sean@verizon.net> wrote:

>It seems you're requesting some really basic template behavior, and if it's not already in D, then I'm surprised and alarmed.
>
>Sean

>> On Wed, 13 Aug 2003 08:16:18 -0600, Benji Smith <dlanguage@xxagg.com> wrote:
>> >
>> >The crux of these suggestions is that we should be able to treat classes defined within a template (and instantiated elsewhere in the code) just like ordinary classes.

> Walter can either confirm or deny it, but I'm not aware of these capabilities in D templates. I don't think you can pass around a template-instantiated object the same way you can pass around a regular object. And I don't think that you can create a class that inherits from a template-instantiated class. Am I wrong?
>
> If it's possible to do these things (see my original post at the top of this thread), the syntax isn't documented anywhere that I'm aware of.
>
> And, yeah, if you can't do these things, we all deserve to be alarmed.
>

I think we should be able to do everything we can in C++ and more and with an easier syntax.

We should be able to do something like that:

template add(int a, int b)
{
    int result = a + b;
}

instance add(3, 4) my_instance;

int [my_instance.result] static_array;

and probably as a shortcut:

int[instance add(3, 4).result] static_array2;

maybe with an extra () like that if necessary..

int[instance add(3, 4)().result] static_array2;

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:522qjvo36o9m11808me54qms0brr9anhr9@4ax.com...
> Does anybody else have an opinion about my template wishlist?

I do. I'm working on some ideas that should help.