"Karl Bochert" <kbochert@copper.net> wrote in message news:1104_1060170085@bose...
> > >
> > > Do any of you wizards comprehend how incomprehensible and ugly that looks to us ordinary programmers?
> > >
> > > The primary goal of the syntax seems to be to allow the existing parser constructs to handle it easily, rather than understandability.
> >
> > Good point. Whilst being *far* from an expert on D's templates, it seems
to
> > me that the current situation is arse 'bout face, and the compiler's
ability
> > to make unambiguous decisions, which is a good thing, is more important
than
> > (i) usability/readability, and (ii) implicit instantiation. This is
> > fallacious.
> >
> > However, I have no answer. Most of the people who appear interested in having templates seem to decry the C++ way of doing things. Maybe once
bit
> > vs boolean (I'm with you Burton) and the libraries (anyone with me on
that
> > one?) issues are resolved, then this is the most important, and probably deserving of most people's attention.
> >
> > I for one would be very interested to hear in detail (presumably from Walter) the design, functioning and rationale of the current template support, and then get a load of clever template-type people to try and
do
> > something non-trivial with the current language.
> >
> > If we cannot create an equivalent to C++'s STL, in power, efficiency and generality, with D's templates, then they are plainly wrong.
> >
> > Matthew
> >
> Aren't templates just a preprocessor on steroids?

No

> Given that they extend the compiler rather than  define code, perhaps they should have a syntax that is different than the rest of the language?

Well they inevitably will in definition. But the question is, I think, whether they should always have in use. It's very simple to construct an example:

If you have a generic algorithm for sorting types, it will need to be able to conduct less-than comparison. (Using pseudo-C++ syntax, since I'm not fluent in D templates atm)

template <typename T>
void bubble_sort_sequence(T[] sequence)
{
   if(sequence.length > 0)
  {
    for(int i = 0; i < sequence.length; ++i)
    {
      for(int j = i; j < sequence.length; ++j)
      {
        if(sequence[j] < sequence[i]) // THIS IS WHERE OPERATOR <() will be
called
        {
          swap(sequence[i], sequence[j]);
        }
      }
    }
  }
}

There would be

Obviously < is implemented by default for int, short, etc.

Consider that we have a type Thing, which is logically less-than comparable, but for which such comparisons cannot be implicitly derived by the compiler

class Thing
{

private:
    int    m_i;
    int    m_j;
}

boolean operator <(Thing th1, Thing th2)
{
    return th1.m_i < th2.m_i;
}

Now, if templates are implicitly instantiated, this all works perfectly well
(assuming that I've written bubble_sort_sequence() correctly ...)

However, if they have to be explicitly instantiated, then either bubble_sort_sequence() would only work for built-in types, or it would need to have something such as the following for non-built-in types

        if(instance (OtherThing) template operator <(sequence[j],
sequence[i]))

and thereby not work for built-in types (meaning that two separate versions would have to be written).

Now I know I've got my D template syntax all screwed-up, but I think you get the picture. Basically, if templates are not implicitly instantiated, then they're going to be almost not worth having.

> Perhaps Walter should do what he did for the preprocessor -- categorize the uses of templates , and provide separate solutions for each?

I don't know what you mean by this.

> Templates seem to be a tool that is too powerful to be allowed in the hands of ordinary programmers.

It is a tool that is open to abuse by inexperienced/incompetent programmers. Do we want a powerful and powerfully expressive language, or do we want to program in Java? (If the latter, then why not just use Java?)

> Make D free with templates as a $1200  option? :-)

:)