Hi Matthew,

Some words about of my position in this question. I use the templates in my day
to day job and my answer the last question: "Make D free with templates as a
$1200  option? :-)" is also :)!
So... The D really has no implicit template arguments deduction that is a
strange for C++ programmer. But who said it is impossible to implement
explicitly in D exactly the same templates/metaclasses you can write by C++?
Now I trying the templates and the syntax looks strange... But till now I
succeeded to receive the needed functionality.
By the way, if it is needed to present different code for standard type and
build-in it is possible by template specification. But I think the code you
wrote (in mixed syntax) will work properly with any type (I didn't try).

Thanks!

P.S. During my experiments with templates I found some bugs and described them today. Till now I received no information... Is it only problem of my compiler version? ;)

In article <bgqvcl$obg$1@digitaldaemon.com>, Matthew Wilson says...
>
>
>"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? :-)
>
>:)
>
>
>