www.digitalmars.com         C & C++   DMDScript  

D - template proposal

reply "Walter" <walter digitalmars.com> writes:
www.digitalmars.com/template.html

Notice how short it is <g>. Ok, what did I miss?
Aug 21 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html
 Notice how short it is <g>. Ok, what did I miss?


First thing I missed was the right url <sigh>

www.digitalmars.com/d/template.html
Aug 21 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:


 "Walter" <walter digitalmars.com> wrote in message
 news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html
 Notice how short it is <g>. Ok, what did I miss?


 First thing I missed was the right url <sigh>

 www.digitalmars.com/d/template.html


max() and min() were presented to me as a classic problem that C++
templates were trying to solve.  The beauty was that there only needed
to be one declaration, and all types automatically got a max()
function.  It was a substitute for C's template solution.  I don't see
how D templates can do max and min, unless you explicitly instantiate
them:
    in Max(int) maxint; val3 = maxint.max(val1,val2);
That seems like an ugly solution to me, especially since (as I
understand it), we can't use the same instantiation name for multiple
different instantiations.  If we're going to have to have a "maxint"
template instantiation that's separate from a "maxfloat" and all the
others, we might as well just define functions and save ourselves 4
characters of typing when we call it.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Aug 21 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
That sounds more like a functional template then a class template. Parhaps D
needs that as well?

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D63793A.93407771 deming-os.org...

 Walter wrote:


 "Walter" <walter digitalmars.com> wrote in message
 news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html
 Notice how short it is <g>. Ok, what did I miss?


 First thing I missed was the right url <sigh>

 www.digitalmars.com/d/template.html


 max() and min() were presented to me as a classic problem that C++
 templates were trying to solve.  The beauty was that there only needed
 to be one declaration, and all types automatically got a max()
 function.  It was a substitute for C's template solution.  I don't see
 how D templates can do max and min, unless you explicitly instantiate
 them:
     in Max(int) maxint; val3 = maxint.max(val1,val2);
 That seems like an ugly solution to me, especially since (as I
 understand it), we can't use the same instantiation name for multiple
 different instantiations.  If we're going to have to have a "maxint"
 template instantiation that's separate from a "maxfloat" and all the
 others, we might as well just define functions and save ourselves 4
 characters of typing when we call it.

 --
 The Villagers are Online! http://villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ak04p5$t3u$1 digitaldaemon.com...

 That sounds more like a functional template then a class template. Parhaps


D

 needs that as well?


D does not have a distinction between class and function templates. An
entire group of declarations of any kind can be within a template body,
including classes, functions, variables, enums, nested templates, etc.
Aug 21 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ak0efd$1lp2$2 digitaldaemon.com...


 D does not have a distinction between class and function templates. An
 entire group of declarations of any kind can be within a template body,
 including classes, functions, variables, enums, nested templates, etc.


   It's like a "template namespace", which is something I've always wanted
in C++.

Salutaciones,
                       JCAB
Aug 21 2002
parent "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> wrote in message
news:ak16eg$2q07$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:ak0efd$1lp2$2 digitaldaemon.com...

 D does not have a distinction between class and function templates. An
 entire group of declarations of any kind can be within a template body,
 including classes, functions, variables, enums, nested templates, etc.


    It's like a "template namespace", which is something I've always wanted
 in C++.


Exactly!
Aug 21 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D63793A.93407771 deming-os.org...

 max() and min() were presented to me as a classic problem that C++
 templates were trying to solve.  The beauty was that there only needed
 to be one declaration, and all types automatically got a max()
 function.  It was a substitute for C's template solution.  I don't see
 how D templates can do max and min, unless you explicitly instantiate
 them:
     in Max(int) maxint; val3 = maxint.max(val1,val2);
 That seems like an ugly solution to me, especially since (as I
 understand it), we can't use the same instantiation name for multiple
 different instantiations.  If we're going to have to have a "maxint"
 template instantiation that's separate from a "maxfloat" and all the
 others, we might as well just define functions and save ourselves 4
 characters of typing when we call it.


You are correct that D does not do C++'s implicit instantiation, in D,
instantiation must be explicit. The reason is I have come to believe that
much of the complexity and problems with C++ templates comes from implicit
instantiation - this is complexity in both specification and use. In
practice, I find that many programs use typedef's to try and reduce the
complexity and approximate explicit instantiation.
Aug 21 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D63793A.93407771 deming-os.org...
 

max() and min() were presented to me as a classic problem that C++
templates were trying to solve.  The beauty was that there only needed
to be one declaration, and all types automatically got a max()
function.  It was a substitute for C's template solution.  I don't see
how D templates can do max and min, unless you explicitly instantiate
them:
    in Max(int) maxint; val3 = maxint.max(val1,val2);
That seems like an ugly solution to me, especially since (as I
understand it), we can't use the same instantiation name for multiple
different instantiations.  If we're going to have to have a "maxint"
template instantiation that's separate from a "maxfloat" and all the
others, we might as well just define functions and save ourselves 4
characters of typing when we call it.


 
 
 You are correct that D does not do C++'s implicit instantiation, in D,
 instantiation must be explicit. The reason is I have come to believe that
 much of the complexity and problems with C++ templates comes from implicit
 instantiation - this is complexity in both specification and use. In
 practice, I find that many programs use typedef's to try and reduce the
 complexity and approximate explicit instantiation.


That was only part of the problem.  I was also concerned about namespace 
cluttering (maxint, maxfloat, etc. instead of just a single "max").
Aug 21 2002
parent "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D63C9DD.3060203 deming-os.org...

 Walter wrote:

 You are correct that D does not do C++'s implicit instantiation, in D,
 instantiation must be explicit. The reason is I have come to believe




that

 much of the complexity and problems with C++ templates comes from




implicit

 instantiation - this is complexity in both specification and use. In
 practice, I find that many programs use typedef's to try and reduce the
 complexity and approximate explicit instantiation.


 That was only part of the problem.  I was also concerned about namespace
 cluttering (maxint, maxfloat, etc. instead of just a single "max").


The advantage of that is you'll get much more reasonable error messages,
rather than things like:

    Error: foo<<<t>bar<<>>>const T>>>***<<T,Q><int <<<>>> bar<q,int*><10>

<g>
Aug 21 2002
prev sibling next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:


 "Walter" <walter digitalmars.com> wrote in message
 news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html
 Notice how short it is <g>. Ok, what did I miss?


 First thing I missed was the right url <sigh>

 www.digitalmars.com/d/template.html


In the "Argument Deduction" section,  I don't understand the Bar(D, D :
D[]) example.  Does this mean that you have only one template parameter,
"D", and you have to specify it in 2 different ways?  If not, then what
does it mean?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D637991.FF91430E deming-os.org...

 In the "Argument Deduction" section,  I don't understand the Bar(D, D :
 D[]) example.  Does this mean that you have only one template parameter,
 "D", and you have to specify it in 2 different ways?  If not, then what
 does it mean?


That defines, to use C++ terminology, a "partial specialization", and is
equivalent to the C++:

    template<class D> int Bar<D, D[]>() { }

It means there are two arguments to the template, and to instantiate it you
need to specify both. While this doesn't make a whole lot of sense by
itself, it is to distinguish Bar(D,D[]) from another template Bar(D,E).
Aug 21 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D637991.FF91430E deming-os.org...
 

In the "Argument Deduction" section,  I don't understand the Bar(D, D :
D[]) example.  Does this mean that you have only one template parameter,
"D", and you have to specify it in 2 different ways?  If not, then what
does it mean?


 
 
 That defines, to use C++ terminology, a "partial specialization", and is
 equivalent to the C++:
 
     template<class D> int Bar<D, D[]>() { }
 
 It means there are two arguments to the template, and to instantiate it you
 need to specify both. While this doesn't make a whole lot of sense by
 itself, it is to distinguish Bar(D,D[]) from another template Bar(D,E).


What is the difference between
     template Bar(D, D : D[]) {...}
and
     template Bar(D : D{}) {...}
?
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D63CB4E.30009 deming-os.org...

 Walter wrote:

 That defines, to use C++ terminology, a "partial specialization", and is
 equivalent to the C++:

     template<class D> int Bar<D, D[]>() { }

 It means there are two arguments to the template, and to instantiate it




you

 need to specify both. While this doesn't make a whole lot of sense by
 itself, it is to distinguish Bar(D,D[]) from another template Bar(D,E).


 What is the difference between
      template Bar(D, D : D[]) {...}
 and
      template Bar(D : D{}) {...}
 ?


The latter is illegal, as D{} is not a type.
Aug 21 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D63CB4E.30009 deming-os.org...
 

Walter wrote:


That defines, to use C++ terminology, a "partial specialization", and is
equivalent to the C++:

    template<class D> int Bar<D, D[]>() { }

It means there are two arguments to the template, and to instantiate it




 you
 

need to specify both. While this doesn't make a whole lot of sense by
itself, it is to distinguish Bar(D,D[]) from another template Bar(D,E).


What is the difference between
     template Bar(D, D : D[]) {...}
and
     template Bar(D : D{}) {...}
?


 
 
 The latter is illegal, as D{} is not a type.


Oops, meant D[] on the latter one
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D63D965.4040809 deming-os.org...

What is the difference between
     template Bar(D, D : D[]) {...}
and
     template Bar(D : D{}) {...}
?


 The latter is illegal, as D{} is not a type.


 Oops, meant D[] on the latter one


In that case, it serves to distinguish:

    instance Bar(int) x1;

from:

    instance Bar(int, int[]) x2;
Aug 21 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D63D965.4040809 deming-os.org...
 

What is the difference between
    template Bar(D, D : D[]) {...}
and
    template Bar(D : D{}) {...}
?


The latter is illegal, as D{} is not a type.


Oops, meant D[] on the latter one


 
 
 In that case, it serves to distinguish:
 
     instance Bar(int) x1;
 
 from:
 
     instance Bar(int, int[]) x2;


And the difference between the two is?
Aug 22 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Thu, 22 Aug 2002 14:02:13 -0700 Russell Lewis 
<spamhole-2001-07-16 deming-os.org> wrote:


 In that case, it serves to distinguish:
 
     instance Bar(int) x1;
 
 from:
 
     instance Bar(int, int[]) x2;


 
 And the difference between the two is?


 
The first one gets one argument, the second gets two. =)
Aug 22 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374913480596065 news.digitalmars.com...

 On Thu, 22 Aug 2002 14:02:13 -0700 Russell Lewis
 <spamhole-2001-07-16 deming-os.org> wrote:

 In that case, it serves to distinguish:
     instance Bar(int) x1;
 from:
     instance Bar(int, int[]) x2;


 And the difference between the two is?


 The first one gets one argument, the second gets two. =)


Yes, that's all it is. Think of it like function overloading.
Aug 23 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374913480596065 news.digitalmars.com...
 

On Thu, 22 Aug 2002 14:02:13 -0700 Russell Lewis
<spamhole-2001-07-16 deming-os.org> wrote:


In that case, it serves to distinguish:
    instance Bar(int) x1;
from:
    instance Bar(int, int[]) x2;


And the difference between the two is?


The first one gets one argument, the second gets two. =)


 
 
 Yes, that's all it is. Think of it like function overloading.


Kind of like
     void foo(int a,int b) in { assert(a == b); } {...}
???

If that's the case, why are we reusing the "Bar" name rather than just 
defining a new template name that only takes one argument???
Aug 23 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
On Fri, 23 Aug 2002 11:21:40 -0700 Russell Lewis 
<spamhole-2001-07-16 deming-os.org> wrote:


 If that's the case, why are we reusing the "Bar" name rather than just 
 defining a new template name that only takes one argument???


It was just an example! It doesn't have to be useful or even have sense. =)
Aug 23 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D667D34.3090803 deming-os.org...

 Walter wrote:

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374913480596065 news.digitalmars.com...


On Thu, 22 Aug 2002 14:02:13 -0700 Russell Lewis
<spamhole-2001-07-16 deming-os.org> wrote:


In that case, it serves to distinguish:
    instance Bar(int) x1;
from:
    instance Bar(int, int[]) x2;


And the difference between the two is?


The first one gets one argument, the second gets two. =)



 Yes, that's all it is. Think of it like function overloading.


 Kind of like
      void foo(int a,int b) in { assert(a == b); } {...}
 ???

 If that's the case, why are we reusing the "Bar" name rather than just
 defining a new template name that only takes one argument???


Because Bar(int, int[]) is a specialization of Bar(T, U).
Aug 23 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D667D34.3090803 deming-os.org...
 

Walter wrote:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374913480596065 news.digitalmars.com...



On Thu, 22 Aug 2002 14:02:13 -0700 Russell Lewis
<spamhole-2001-07-16 deming-os.org> wrote:



In that case, it serves to distinguish:
   instance Bar(int) x1;
from:
   instance Bar(int, int[]) x2;


And the difference between the two is?


The first one gets one argument, the second gets two. =)



Yes, that's all it is. Think of it like function overloading.


Kind of like
     void foo(int a,int b) in { assert(a == b); } {...}
???

If that's the case, why are we reusing the "Bar" name rather than just
defining a new template name that only takes one argument???


 
 
 Because Bar(int, int[]) is a specialization of Bar(T, U).


Ok, got you so far.  So why declare it as
     template Bar(D, D : D[]) {...}
rather than
     template Bar(D, UNUSED_PARAM : D[]) {...}
???

The former looks like you're declaring the same parameter twice, with 
two different usages.
Aug 26 2002
parent "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D6A69CC.5050106 deming-os.org...

 Because Bar(int, int[]) is a specialization of Bar(T, U).


 Ok, got you so far.  So why declare it as
      template Bar(D, D : D[]) {...}
 rather than
      template Bar(D, UNUSED_PARAM : D[]) {...}
 ???

 The former looks like you're declaring the same parameter twice, with
 two different usages.


It could be:
    (D, :D[])
but I thought the : might appear invisible like that.
Aug 26 2002
prev sibling parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Walter" <walter digitalmars.com> wrote in message
 news:ajvgsb$6gt$1 digitaldaemon.com...
 

www.digitalmars.com/template.html
Notice how short it is <g>. Ok, what did I miss?


 
 
 First thing I missed was the right url <sigh>
 
 www.digitalmars.com/d/template.html
 
 
 



Can you nest templates?  Would it be useful to be able to derive one 
template from another (to add memebers, not to override them)?
Aug 21 2002
parent "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D63DF06.6030202 deming-os.org...

 Can you nest templates?


Yes.


 Would it be useful to be able to derive one
 template from another (to add memebers, not to override them)?


Uh-oh! Maybe for V3 of the language!
Aug 21 2002
prev sibling next sibling parent reply "anderson" <anderson firestar.com.au> writes:
Looks pretty complete for my needs (although I'm no template expert). Simple
yet powerful. Just a few questions.

"
template Foo(T);
 in Foo(int); // T is deduced to be int
 in Foo(char*); // T is deduced to be char*
"
I don't understand this where is the InstanceIdentifier? Or is this some
type of overloaded function call?

I guess this is a stupid question, but will it support operator overloading?

"Walter" <walter digitalmars.com> wrote in message
news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html

 Notice how short it is <g>. Ok, what did I miss?
Aug 21 2002
parent "Walter" <walter digitalmars.com> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ajvr5q$i69$1 digitaldaemon.com...

 Looks pretty complete for my needs (although I'm no template expert).


Simple

 yet powerful. Just a few questions.

 "
 template Foo(T);
  in Foo(int); // T is deduced to be int
  in Foo(char*); // T is deduced to be char*
 "
 I don't understand this where is the InstanceIdentifier? Or is this some
 type of overloaded function call?


I forgot to put in the InstanceIdentifier. Oops!


 I guess this is a stupid question, but will it support operator


overloading?

Sure.
Aug 21 2002
prev sibling next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
1. I would prefer something other than 'in' for 'instantiation'.  I realize that
'instance' might be annoying to type, but I will never be able to look at 'in'
and see anything except 'the opposite of out'.  I could go with 'inst', which
contains enough of the word to suggest 'instance' to me.  (I have similar
problems with the standard C++ STL notation of InIt for an Input Iterator -- it
just looks like an initializer to me...)

2. How do I make two variables of type Foo(int)?  According to the
documentation, this appears to be explicitly disallowed -- "Multiple
instantiations of a TemplateDeclaration with the same TemplateParameterList all
will refer to the same instantiation."  If I make a RedBlackTree(T), and then
find myself needing two separate trees that both hold char[]s, how can I do
that?  I *could* typedef two different names for char[]s and make separate
instances that way, but that just obscures the issue.  Readers of the code then
have to go look up my typedef to find out that it is just a char[] with no
additional functionality.

3. It might be useful to have some way to say that some template parameters are
"like" or "derived from" other template parameters:

template Cage(Base, Derived like Base) {/*whatever*/}

Then at instantiation:

inst Cage(Bird, Cockateel);    // OK, assuming Cockateel derives from Bird
inst Cage(Bird, Bird);         // OK
inst Cage(Bird, Collie);       // Error - Collie does not derive from Bird
inst Cage(Bird, Animal);       // Error - inheritance order is backwards

I'm not sure how useful this is in practice.  I know Eiffel has a similar
system, and Bertrand Meyer gets really excited about it, but I was never certain
that I saw the benefit of this over using Base*s and letting vtables handle it.

4. I would really like constrained genericity.  Similar to the above, but when
you say a parameter is "like" some base class, the base class doesn't need to be
another parameter to the template.

template Calculator(T like NUMERIC) {/*whatever*/}

In this case, NUMERIC is basically an interface.  The standard argument against
this is that if someone tries to instantiate the template with a class that is
not NUMERIC, something will fail when Calculator tries to use one of the NUMERIC
members.  But it is possible (even if unlikely) that a non-NUMERIC class could
accidentally implement enough of NUMERIC to let it work, but not work the way
Calculator expects.  Calculator is a bad example of this, since anyone providing
NUMERIC-style members probably is doing numerical work -- but for other
templates and other interfaces, the issue is not as clear.  The other benefit is
self-documentation.  By placing it in the code, the developer makes it clear
what he/she is requiring for the template parameter.  It becomes part of the
contract.

I have no particular attachment to the word "like" in either of the above
points.  It just happened to be the first thing I thought of.  "implements"
might not be a bad choice, although it is rather wordy ( T implements NUMERIC ).
"isa" or "is_a" might work too ( T isa NUMERIC ).

Mac
Aug 21 2002
next sibling parent Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Mac Reiter wrote:

 1. I would prefer something other than 'in' for 'instantiation'.  I realize
that
 'instance' might be annoying to type, but I will never be able to look at 'in'
 and see anything except 'the opposite of out'.  I could go with 'inst', which
 contains enough of the word to suggest 'instance' to me.  (I have similar
 problems with the standard C++ STL notation of InIt for an Input Iterator -- it
 just looks like an initializer to me...)


Hear, Hear


 2. How do I make two variables of type Foo(int)?  According to the
 documentation, this appears to be explicitly disallowed -- "Multiple
 instantiations of a TemplateDeclaration with the same TemplateParameterList all
 will refer to the same instantiation."  If I make a RedBlackTree(T), and then
 find myself needing two separate trees that both hold char[]s, how can I do
 that?  I *could* typedef two different names for char[]s and make separate
 instances that way, but that just obscures the issue.  Readers of the code then
 have to go look up my typedef to find out that it is just a char[] with no
 additional functionality.


As I understand it, the code would be
     in RedBlackTree(char[]) RedBlackTree_of_char_array;
     RedBlackTree_of_char_array var1;
     RedBlackTree_of_char_array var2;
Aug 21 2002
prev sibling next sibling parent reply Suporte Internet <suporte spica.mps.com.br> writes:
Mac Reiter <Mac_member pathlink.com> wrote:

 1. I would prefer something other than 'in' for 'instantiation'.  I realize
that
 'instance' might be annoying to type, but I will never be able to look at 'in'
 and see anything except 'the opposite of out'.  I could go with 'inst', which
 contains enough of the word to suggest 'instance' to me.  (I have similar
 problems with the standard C++ STL notation of InIt for an Input Iterator -- it


Why not use the keyword "typedef" ?
This is not what is doing ? You are creating a new type based on a
template ?
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Suporte Internet" <suporte spica.mps.com.br> wrote in message
news:ak0dea$1ich$1 digitaldaemon.com...

 Why not use the keyword "typedef" ?
 This is not what is doing ? You are creating a new type based on a
 template ?


typedef is a good idea, the trouble comes from distinguishing a typedef from
a declaration just by
the syntax:

    typedef foo(int*) f;
Aug 21 2002
parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Suporte Internet" <suporte spica.mps.com.br> wrote in message
 news:ak0dea$1ich$1 digitaldaemon.com...
 

Why not use the keyword "typedef" ?
This is not what is doing ? You are creating a new type based on a
template ?


 
 
 typedef is a good idea, the trouble comes from distinguishing a typedef from
 a declaration just by
 the syntax:
 
     typedef foo(int*) f;


You could go the old C route:
     typedef template foo(int*) f;
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D63CB8E.3030608 deming-os.org...

 Walter wrote:

 "Suporte Internet" <suporte spica.mps.com.br> wrote in message
 news:ak0dea$1ich$1 digitaldaemon.com...

Why not use the keyword "typedef" ?
This is not what is doing ? You are creating a new type based on a
template ?


 typedef is a good idea, the trouble comes from distinguishing a typedef




from

 a declaration just by
 the syntax:
     typedef foo(int*) f;


 You could go the old C route:
      typedef template foo(int*) f;


I think I'd rather use the keyword 'instance' <g>.
Aug 21 2002
parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Walter" <walter digitalmars.com> wrote in message
news:ak0j61$1r42$2 digitaldaemon.com...

 I think I'd rather use the keyword 'instance' <g>.


Couldn't it cause some confusion with instances of classes, which are
objects? Instances of a template is an interely different thing. How about
"concrete", meaning that you make the abstract template concrete by
supplying types.

Regards,
Martin M. Pedersen
Aug 21 2002
parent "Walter" <walter digitalmars.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ak0sto$ic1$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:ak0j61$1r42$2 digitaldaemon.com...

 I think I'd rather use the keyword 'instance' <g>.


 Couldn't it cause some confusion with instances of classes, which are
 objects? Instances of a template is an interely different thing. How about
 "concrete", meaning that you make the abstract template concrete by
 supplying types.


It could, but instantiations of templates, as well as instantiations of
classes, are both commonly referred to as instances. Your point is likely
why Ada instantiates templates with the 'new' keyword.
Aug 21 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak09pv$1b4k$1 digitaldaemon.com...

 1. I would prefer something other than 'in' for 'instantiation'.  I


realize that

 'instance' might be annoying to type, but I will never be able to look at


'in'

 and see anything except 'the opposite of out'.  I could go with 'inst',


which

 contains enough of the word to suggest 'instance' to me.  (I have similar
 problems with the standard C++ STL notation of InIt for an Input


Iterator -- it

 just looks like an initializer to me...)


I was afraid that 'instance' just was too long. An alternative is to use
'new' sort of like Ada. But you might be right.


 2. How do I make two variables of type Foo(int)?


You don't - Foo is a template, not a type. A type could be declared inside
the template:

    template Foo(T) { typedef T abc; }
    instance Foo(int) myfoo;
    // Declare multiple variables:
    myfoo.abc var1;
    myfoo.abc var2;


 According to the
 documentation, this appears to be explicitly disallowed -- "Multiple
 instantiations of a TemplateDeclaration with the same


TemplateParameterList all

 will refer to the same instantiation."  If I make a RedBlackTree(T), and


then

 find myself needing two separate trees that both hold char[]s, how can I


do

 that?  I *could* typedef two different names for char[]s and make separate
 instances that way, but that just obscures the issue.  Readers of the code


then

 have to go look up my typedef to find out that it is just a char[] with no
 additional functionality.


In that case, it sounds like one should write:

    template RedBlackTree(T)
    {
        class Foo
        { char[] s;
        }
    }

    instance RedBlackTree(whatever) mytree;

    // Now create multiple independent trees, each with their own data:
    mytree.Foo f = new mytree(Foo);
    mytree.Foo g = new mytree(Foo);


 3. It might be useful to have some way to say that some template


parameters are

 "like" or "derived from" other template parameters:

 template Cage(Base, Derived like Base) {/*whatever*/}

 Then at instantiation:

 inst Cage(Bird, Cockateel);    // OK, assuming Cockateel derives from Bird
 inst Cage(Bird, Bird);         // OK
 inst Cage(Bird, Collie);       // Error - Collie does not derive from Bird
 inst Cage(Bird, Animal);       // Error - inheritance order is backwards

 I'm not sure how useful this is in practice.  I know Eiffel has a similar
 system, and Bertrand Meyer gets really excited about it, but I was never


certain

 that I saw the benefit of this over using Base*s and letting vtables


handle it.

That could possibly be handled by a contract:

    template Cage(Base, Derived)
    {
        class Foo
        {
            Base b;
            Derived d;
            invariant { assert(cast(Base)d != null); }
        }
    }


 4. I would really like constrained genericity.  Similar to the above, but


when

 you say a parameter is "like" some base class, the base class doesn't need


to be

 another parameter to the template.

 template Calculator(T like NUMERIC) {/*whatever*/}

 In this case, NUMERIC is basically an interface.  The standard argument


against

 this is that if someone tries to instantiate the template with a class


that is

 not NUMERIC, something will fail when Calculator tries to use one of the


NUMERIC

 members.  But it is possible (even if unlikely) that a non-NUMERIC class


could

 accidentally implement enough of NUMERIC to let it work, but not work the


way

 Calculator expects.  Calculator is a bad example of this, since anyone


providing

 NUMERIC-style members probably is doing numerical work -- but for other
 templates and other interfaces, the issue is not as clear.  The other


benefit is

 self-documentation.  By placing it in the code, the developer makes it


clear

 what he/she is requiring for the template parameter.  It becomes part of


the

 contract.


That is a good suggestion. Note that there are already ways to constrain it
to be, say, an array type:

    template Foo(T : T[])
Aug 21 2002
parent reply Mac Reiter <Mac_member pathlink.com> writes:
 2. How do I make two variables of type Foo(int)?


You don't - Foo is a template, not a type. A type could be declared inside
the template:

    template Foo(T) { typedef T abc; }
    instance Foo(int) myfoo;
    // Declare multiple variables:
    myfoo.abc var1;
    myfoo.abc var2;


Thank you.  I hadn't quite grokked that a template was a thing entirely to
itself.  The extra level of indirection (myfoo.abc rather than just abc(int))
had not really clicked.  Now that I see that, the RedBlack(char) question goes
away.

I really like being able to make an arbitrary amount of stuff inside a template,
all based on the same instantiation parameters.  I'll have to think about it
some more before I can give any useful feedback...

Mac
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak0ltg$2hjd$1 digitaldaemon.com...

 Thank you.  I hadn't quite grokked that a template was a thing entirely to
 itself.  The extra level of indirection (myfoo.abc rather than just


abc(int))

 had not really clicked.  Now that I see that, the RedBlack(char) question


goes

 away.


Yup. It's perilous to break from the C++ mindset on how it should work <g>.


 I really like being able to make an arbitrary amount of stuff inside a


template,

 all based on the same instantiation parameters.  I'll have to think about


it

 some more before I can give any useful feedback...


It has the nice feature of simply chucking the whole C++ messy distinctions
between template classes, template functions, member template functions (or
is it template member functions?), etc. In many more complex cases of this,
it can get really tricky for the C++ compiler to parse which is which. In D,
the template syntax is a no-brainer to implement. (Semantic analysis is a
little harder!)
Aug 21 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ak0rom$app$2 digitaldaemon.com...

 "Mac Reiter" <Mac_member pathlink.com> wrote in message
 news:ak0ltg$2hjd$1 digitaldaemon.com...

 Thank you.  I hadn't quite grokked that a template was a thing entirely




to

 itself.  The extra level of indirection (myfoo.abc rather than just


 abc(int))

 had not really clicked.  Now that I see that, the RedBlack(char)




question

 goes

 away.


 Yup. It's perilous to break from the C++ mindset on how it should work


<g>.

But do we want that extra indirection, after all?
In practice you usually need class templates.
You will end up typedef-ing everything, to avoid the burden of the
unnecessary indirection.

typedef   RedBlackTree  instance RBT_Template(char).TheClassInside;

Makes me feel like Java, with all the superfluous indirections.
And class templates also allow for function templates as static member
functions.

Sorry if this was already metioned. I don't have the time to read all the
hundreds of mails in this thread.

Yours,
Sandor
Aug 26 2002
parent "Walter" <walter digitalmars.com> writes:
"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:akd51e$1hvo$1 digitaldaemon.com...

 But do we want that extra indirection, after all?
 In practice you usually need class templates.
 You will end up typedef-ing everything, to avoid the burden of the
 unnecessary indirection.

 typedef   RedBlackTree  instance RBT_Template(char).TheClassInside;
 Makes me feel like Java, with all the superfluous indirections.
 And class templates also allow for function templates as static member
 functions.


Yes, it's a little more typing, but I think that it makes things a lot
clearer.
Aug 26 2002
prev sibling next sibling parent Jason Mills <jmills cs.mun.ca> writes:
Mac Reiter wrote:

 1. I would prefer something other than 'in' for 'instantiation'.  I realize
that
 'instance' might be annoying to type, but I will never be able to look at 'in'
 and see anything except 'the opposite of out'.  I could go with 'inst', which
 contains enough of the word to suggest 'instance' to me.  (I have similar
 problems with the standard C++ STL notation of InIt for an Input Iterator -- it
 just looks like an initializer to me...)


I agree. In addition, "in" is already used for "in" parameters and "in" 
contracts.


 2. How do I make two variables of type Foo(int)?  According to the
 documentation, this appears to be explicitly disallowed -- "Multiple
 instantiations of a TemplateDeclaration with the same TemplateParameterList all
 will refer to the same instantiation."  If I make a RedBlackTree(T), and then
 find myself needing two separate trees that both hold char[]s, how can I do
 that?  I *could* typedef two different names for char[]s and make separate
 instances that way, but that just obscures the issue.  Readers of the code then
 have to go look up my typedef to find out that it is just a char[] with no
 additional functionality.
 
 3. It might be useful to have some way to say that some template parameters are
 "like" or "derived from" other template parameters:
 
 template Cage(Base, Derived like Base) {/*whatever*/}
 
 Then at instantiation:
 
 inst Cage(Bird, Cockateel);    // OK, assuming Cockateel derives from Bird
 inst Cage(Bird, Bird);         // OK
 inst Cage(Bird, Collie);       // Error - Collie does not derive from Bird
 inst Cage(Bird, Animal);       // Error - inheritance order is backwards
 
 I'm not sure how useful this is in practice.  I know Eiffel has a similar
 system, and Bertrand Meyer gets really excited about it, but I was never
certain
 that I saw the benefit of this over using Base*s and letting vtables handle it.
 
 4. I would really like constrained genericity.  Similar to the above, but when
 you say a parameter is "like" some base class, the base class doesn't need to
be
 another parameter to the template.
 
 template Calculator(T like NUMERIC) {/*whatever*/}
 
 In this case, NUMERIC is basically an interface.  The standard argument against
 this is that if someone tries to instantiate the template with a class that is
 not NUMERIC, something will fail when Calculator tries to use one of the
NUMERIC
 members.  But it is possible (even if unlikely) that a non-NUMERIC class could
 accidentally implement enough of NUMERIC to let it work, but not work the way
 Calculator expects.  Calculator is a bad example of this, since anyone
providing
 NUMERIC-style members probably is doing numerical work -- but for other
 templates and other interfaces, the issue is not as clear.  The other benefit
is
 self-documentation.  By placing it in the code, the developer makes it clear
 what he/she is requiring for the template parameter.  It becomes part of the
 contract.
 
 I have no particular attachment to the word "like" in either of the above
 points.  It just happened to be the first thing I thought of.  "implements"
 might not be a bad choice, although it is rather wordy ( T implements NUMERIC
).
 "isa" or "is_a" might work too ( T isa NUMERIC ).
 
 Mac
Aug 21 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak09pv$1b4k$1 digitaldaemon.com...

 3. It might be useful to have some way to say that some template


parameters are

 "like" or "derived from" other template parameters:

 template Cage(Base, Derived like Base) {/*whatever*/}

 Then at instantiation:

 inst Cage(Bird, Cockateel);    // OK, assuming Cockateel derives from Bird
 inst Cage(Bird, Bird);         // OK
 inst Cage(Bird, Collie);       // Error - Collie does not derive from Bird
 inst Cage(Bird, Animal);       // Error - inheritance order is backwards

 I'm not sure how useful this is in practice.  I know Eiffel has a similar
 system, and Bertrand Meyer gets really excited about it, but I was never


certain

 that I saw the benefit of this over using Base*s and letting vtables


handle it.

 4. I would really like constrained genericity.  Similar to the above, but


when

 you say a parameter is "like" some base class, the base class doesn't need


to be

 another parameter to the template.

 template Calculator(T like NUMERIC) {/*whatever*/}

 In this case, NUMERIC is basically an interface.  The standard argument


against

 this is that if someone tries to instantiate the template with a class


that is

 not NUMERIC, something will fail when Calculator tries to use one of the


NUMERIC

 members.  But it is possible (even if unlikely) that a non-NUMERIC class


could

 accidentally implement enough of NUMERIC to let it work, but not work the


way

 Calculator expects.  Calculator is a bad example of this, since anyone


providing

 NUMERIC-style members probably is doing numerical work -- but for other
 templates and other interfaces, the issue is not as clear.  The other


benefit is

 self-documentation.  By placing it in the code, the developer makes it


clear

 what he/she is requiring for the template parameter.  It becomes part of


the

 contract.


It occurs to me that this does fit in with the D template syntax:

    template Calculator(T : NUMERIC) { ... }

means that T can be either NUMERIC or a class derived from NUMERIC (if
NUMERIC is a class or interface). Your case 3 would be:

    template Cage(B, D : B) {/*whatever*/}

which would constrain D to be the same as B or derived from B.
Aug 21 2002
next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <ak0rom$app$3 digitaldaemon.com>, Walter says...

"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak09pv$1b4k$1 digitaldaemon.com...

 3. It might be useful to have some way to say that some template


parameters are

 "like" or "derived from" other template parameters:

 template Cage(Base, Derived like Base) {/*whatever*/}

 Then at instantiation:

 inst Cage(Bird, Cockateel);    // OK, assuming Cockateel derives from Bird
 inst Cage(Bird, Bird);         // OK
 inst Cage(Bird, Collie);       // Error - Collie does not derive from Bird
 inst Cage(Bird, Animal);       // Error - inheritance order is backwards




[clip]

 template Calculator(T like NUMERIC) {/*whatever*/}




[clip]

It occurs to me that this does fit in with the D template syntax:

    template Calculator(T : NUMERIC) { ... }

means that T can be either NUMERIC or a class derived from NUMERIC (if
NUMERIC is a class or interface). Your case 3 would be:

    template Cage(B, D : B) {/*whatever*/}

which would constrain D to be the same as B or derived from B.


Even better.  The 'T : NUMERIC' syntax is much like the Eiffel syntax I was
coming from.  I didn't know if it would work that way in D or not.  The examples
with : were demonstrating partial template specialization (or the D equivalent)
and the ability to pull types out of pointers to / arrays of types.  I didn't
know if the constraint system supported general purpose "is a" constraints,
including direct and indirect inheritance.

There appears to be some semantic difference:

template Calc(T : NUMERIC)
template Other(T : T[])

In the first case, I would instantiate Calc with a class that was derived from
NUMERIC (or NUMERIC itself, if NUMERIC is concrete).  But in the second case, I
instantiate Calc with an array, and the compiler extracts the type.  If these
two cases behaved identically, then either:

1. Take the first example as the standard -- Other must now be instantiated with
a single variable, and the type of that variable is required to support the
interface of an array of that type.  T is required to act as if it is an array
of T, which it can't do.

2. Take the second example as the standard -- Calc must now be instantiated with
a NUMERIC, and the D compiler will deduce an appropriate type for T.  I suppose
this would be possible with RTTI, or by allowing the compiler to take
derivatives of NUMERIC directly...

I guess my mental hangup is that 'T:NUMERIC' means "T must support the NUMERIC
interface" (derive from it, whatever), but 'T:T[]' means "given a T[], extract
T".  Having had Eiffel training in constrained genericity, I tend to favor the
"must support" semantics, but I am trying to maintain an open mind...

I know that you've been thinking about this for quite some time, and I also know
that it is difficult to come up with small simple examples that illustrate the
intended usage of some of these features.  (My examples when trying to show this
stuff to my coworkers is almost always horrible)  The 'template X(T,T:T[])'
examples so far seem like they shouldn't need the second parameter, since if you
know T you can always make a T[] inside the template.  In C++ you need this sort
of thing in case the user is using smart array classes, smart pointer classes,
iterators, etc.  But in D, arrays are arrays, pointers are pointers, etc, so
there doesn't seem to be the need to allow the user to specify *how* to make an
array out of the base type.  Could you give us an example (even if it is
somewhat complicated) of the case you were considering when you made the
'template X(T,T:T[])' behavior?  I'm sure there's a reason that I'm just
overlooking.

Thanks,
Mac
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak0tm6$njk$1 digitaldaemon.com...

 There appears to be some semantic difference:

 template Calc(T : NUMERIC)
 template Other(T : T[])

 In the first case, I would instantiate Calc with a class that was derived


from

 NUMERIC (or NUMERIC itself, if NUMERIC is concrete).  But in the second


case, I

 instantiate Calc with an array, and the compiler extracts the type.  If


these

 two cases behaved identically, then either:

 1. Take the first example as the standard -- Other must now be


instantiated with

 a single variable, and the type of that variable is required to support


the

 interface of an array of that type.  T is required to act as if it is an


array

 of T, which it can't do.

 2. Take the second example as the standard -- Calc must now be


instantiated with

 a NUMERIC, and the D compiler will deduce an appropriate type for T.  I


suppose

 this would be possible with RTTI, or by allowing the compiler to take
 derivatives of NUMERIC directly...

 I guess my mental hangup is that 'T:NUMERIC' means "T must support the


NUMERIC

 interface" (derive from it, whatever), but 'T:T[]' means "given a T[],


extract

 T".  Having had Eiffel training in constrained genericity, I tend to favor


the

 "must support" semantics, but I am trying to maintain an open mind...


You're right, there is a subtle difference there. I think if the rule were
if T is in the specialization, then the value of T is extracted. If T is not
in the specialization, T is whatever the whole specialization type is (or
derived from it).


 I know that you've been thinking about this for quite some time, and I


also know

 that it is difficult to come up with small simple examples that illustrate


the

 intended usage of some of these features.  (My examples when trying to


show this

 stuff to my coworkers is almost always horrible)  The 'template


X(T,T:T[])'

 examples so far seem like they shouldn't need the second parameter, since


if you

 know T you can always make a T[] inside the template.  In C++ you need


this sort

 of thing in case the user is using smart array classes, smart pointer


classes,

 iterators, etc.  But in D, arrays are arrays, pointers are pointers, etc,


so

 there doesn't seem to be the need to allow the user to specify *how* to


make an

 array out of the base type.  Could you give us an example (even if it is
 somewhat complicated) of the case you were considering when you made the
 'template X(T,T:T[])' behavior?  I'm sure there's a reason that I'm just
 overlooking.


I don't have a good example. One thing about C++, there seems to be a
veritable army of very smart people discovering clever things to do with C++
templates that weren't anticipated in the initial design of templates. The
X(T,T:T[]) falls out of the specialization syntax, so there's no obvious
reason to disallow it.
Aug 21 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ak11s6$1lac$1 digitaldaemon.com...


 You're right, there is a subtle difference there. I think if the rule were
 if T is in the specialization, then the value of T is extracted. If T is


not

 in the specialization, T is whatever the whole specialization type is (or
 derived from it).


   Or you can use a different operator to make it even simpler to parse. =>
and := come to mind...

   Still, using runtime interfaces for this sounds a little wrong to me.

   One thing that I don't like is not having numeric/value template
parameters.

   And, now that we're at it, "TemplateInstantiations are always performed
in the scope of where the TemplateDeclaration is declared, with the addition
of the template parameters being declared as aliases for their deduced
types", so what's the semantics of this:

---
void func(int) { ... }

template Tpl(T) {
  void anotherfunc(T t) {
    func(t);
  }
}

void func(bool) { ... }

instance Tpl(bool) tplBool; // How?

tplBool.anotherfunc(false); // How?
---

   I guess that with the non-need for function prototypes, this particular
example is solvable in D. But I'm thinking especially of templates defined
in one module and used in another.

Salutaciones,
                       JCAB
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> wrote in message
news:ak1fat$2c87$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:ak11s6$1lac$1 digitaldaemon.com...

 You're right, there is a subtle difference there. I think if the rule




were

 if T is in the specialization, then the value of T is extracted. If T is


 not

 in the specialization, T is whatever the whole specialization type is




(or

 derived from it).


    Or you can use a different operator to make it even simpler to parse.


=>

 and := come to mind...
    Still, using runtime interfaces for this sounds a little wrong to me.


It's still compile time, just a bit extra work for the semantic pass. Not
too tough, C++ templates are far worse <g>. I just have to adapt the
argument type deduction code from that, meanwhile whacking off about 90% of
it.


    One thing that I don't like is not having numeric/value template
 parameters.


Just use them as class members, and pass the class type.


    And, now that we're at it, "TemplateInstantiations are always performed
 in the scope of where the TemplateDeclaration is declared, with the


addition

 of the template parameters being declared as aliases for their deduced
 types", so what's the semantics of this:

 ---
 void func(int) { ... }

 template Tpl(T) {
   void anotherfunc(T t) {
     func(t);
   }
 }

 void func(bool) { ... }

 instance Tpl(bool) tplBool; // How?

 tplBool.anotherfunc(false); // How?


It doesn't matter if some functions are before and some after the use of it,
the compiler sees all of them when doing the semantic analysis. This just
doesn't have the problems/bugs inherent in the C++ model of not knowing
about anything ahead of it in the source file. Hence, the call func(t) will
resolve to func(bool), regardless of the lexical positioning of func(int)
and func(bool).




    I guess that with the non-need for function prototypes, this particular
 example is solvable in D. But I'm thinking especially of templates defined
 in one module and used in another.


If func() is defined in a different module than template Tpl() and is not
visible in the scope of template Tpl(), then you'll get a "func undefined"
message when the instance Tpl(bool) is compiled regardless of whether func()
is visible at the scope of instance Tpl(bool) or not.

This is fundamentally different than the way C++ works - C++ tries to do it
both ways, with some names getting resolved at template declaration scope,
and some at template instantiation scope, depending on whether a name is
"type-dependent" or not.
Aug 21 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ak1k42$j5f$1 digitaldaemon.com...


    Still, using runtime interfaces for this sounds a little wrong to me.


 It's still compile time, just a bit extra work for the semantic pass.


   Hmmm... I guess...


 It doesn't matter if some functions are before and some after the use of


it,

 the compiler sees all of them when doing the semantic analysis.


   Ok... I figured that.


    I guess that with the non-need for function prototypes, this




particular

 example is solvable in D. But I'm thinking especially of templates




defined

 in one module and used in another.


 If func() is defined in a different module than template Tpl() and is not
 visible in the scope of template Tpl(), then you'll get a "func undefined"
 message when the instance Tpl(bool) is compiled regardless of whether


func()

 is visible at the scope of instance Tpl(bool) or not.


   So you can't really use templates taken from a library with user-defined
types unless those user defined types are already known to the library?


 This is fundamentally different than the way C++ works - C++ tries to do


it

 both ways, with some names getting resolved at template declaration scope,
 and some at template instantiation scope, depending on whether a name is
 "type-dependent" or not.


   Yes, and we agree that's bad. Still, unless you have a clever answer to
this, I can't see how your solution is good enough.

   I know you don't like forward declarations, but they might be warranted
in the case of templates:

template Tpl(T) {
  exists void func(T); // forward declaration...
  void anotherfunc(T t) {
    func(t);
  }
}

   This would allow you to eliminate all problems with dependent names.
It'll also allow the compiler to do even better error messages for invalid
instantiations. In a way, you can consider this as compile-time contracts
for templates.

Salutaciones,
                       JCAB
Aug 22 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Thu, 22 Aug 2002 12:58:44 -0700 "Juan Carlos Arevalo Baeza" 
<jcab JCABs-Rumblings.com> wrote:


    So you can't really use templates taken from a library with user-defined
 types unless those user defined types are already known to the library?


You can, as long as you pass those types as template parameters.
Aug 22 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374913474843634 news.digitalmars.com...


    So you can't really use templates taken from a library with




user-defined

 types unless those user defined types are already known to the library?


 You can, as long as you pass those types as template parameters.


   But not unless those types were visible at the point where the template
was declared. So:

--- mylibrary.d
template Tpl(T) { ... }
---

--- myprogram.d
using mylibrary;

class MyClass { ... }

instance Tpl(MyClass) TplMyClass; // Fails!!!
---

   That's what Walter seems to be saying. That the instantiation fails
because MyClass is not visible in mylibrary.d. And that's what I have a
problem with.

Salutaciones,
                       JCAB
Aug 23 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Fri, 23 Aug 2002 10:50:45 -0700 "Juan Carlos Arevalo Baeza" 
<jcab JCABs-Rumblings.com> wrote:


 "Pavel Minayev" <evilone omen.ru> wrote in message
 --- mylibrary.d
 template Tpl(T) { ... }
 ---
 
 --- myprogram.d
 using mylibrary;
 
 class MyClass { ... }
 
 instance Tpl(MyClass) TplMyClass; // Fails!!!
 ---


I think you CAN do it. What Walter meant is that you can use MyClass directly 
from
Tpl if it is declared in the same module with Tpl. Otherwise, you have to pass 
it
as a template argument.
Aug 23 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374919430425 news.digitalmars.com...


 --- mylibrary.d
 template Tpl(T) { ... }
 ---

 --- myprogram.d
 using mylibrary;

 class MyClass { ... }

 instance Tpl(MyClass) TplMyClass; // Fails!!!
 ---


 I think you CAN do it. What Walter meant is that you can use MyClass


directly

 from
 Tpl if it is declared in the same module with Tpl. Otherwise, you have to


pass

 it
 as a template argument.


   Well, that's not what I was asking to Walter.

"TemplateInstantiations are always performed
in the scope of where the TemplateDeclaration is declared, with the addition
of the template parameters being declared as aliases for their deduced
types"

   Let's update my second example:

--- mylibrary.d
template Tpl(T) {
  void tplfunc(T t) {
    func(t);
  }
}
---

--- myprogram.d
using mylibrary;

class MyClass { ... }

void func(MyClass) { ... }

instance Tpl(MyClass) TplMyClass; // Fails!!!
---

Salutaciones,
                       JCAB
Aug 23 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> wrote in message
news:ak687r$2h6e$1 digitaldaemon.com...

 "TemplateInstantiations are always performed
 in the scope of where the TemplateDeclaration is declared, with the


addition

 of the template parameters being declared as aliases for their deduced
 types"

    Let's update my second example:

 --- mylibrary.d
 template Tpl(T) {
   void tplfunc(T t) {
     func(t);
   }
 }
 ---

 --- myprogram.d
 using mylibrary;

 class MyClass { ... }

 void func(MyClass) { ... }

 instance Tpl(MyClass) TplMyClass; // Fails!!!


Yes, that will fail. To make it work, func(MyClass) would need to be a class
member of some class passed as a template argument.
Aug 23 2002
parent Pavel Minayev <evilone omen.ru> writes:
On Fri=2C 23 Aug 2002 20=3A40=3A15 -0700 =22Walter=22
=3Cwalter=40digitalmars=2Ecom=3E wrote=3A

=3E=3E    Let's update my second example=3A
=3E=3E
=3E=3E --- mylibrary=2Ed
=3E=3E template Tpl=28T=29 {
=3E=3E   void tplfunc=28T t=29 {
=3E=3E     func=28t=29=3B
=3E=3E   }
=3E=3E }
=3E=3E ---
=3E=3E
=3E=3E --- myprogram=2Ed
=3E=3E using mylibrary=3B
=3E=3E
=3E=3E class MyClass { =2E=2E=2E }
=3E=3E
=3E=3E void func=28MyClass=29 { =2E=2E=2E }
=3E=3E
=3E=3E instance Tpl=28MyClass=29 TplMyClass=3B =2F=2F Fails!!!
=3E 
=3E Yes=2C that will fail=2E To make it work=2C func=28MyClass=29 would need to
be a class
=3E member of some class passed as a template argument=2E
 
To fix it=3A

=09template Tpl=28T=2C Func=29
=09{
=09=09void tplfunc=28T t=29 { Func=2Ecall=28t=29=3B }
=09}

=09class MyClass { =2E=2E=2E }

=09void func=28MyClass=29 { =2E=2E=2E }

=09class Func=5FMyClass
=09{
=09=09static void call=28MyClass x=29 { func x=3B }
=09}

=09instance Tpl=28MyClass=2C Func=5FMyClass=29 TplMyClass=3B    =2F=2F Works!
Aug 24 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> wrote in message
news:ak5s95$24i6$1 digitaldaemon.com...

    But not unless those types were visible at the point where the template
 was declared. So:

 --- mylibrary.d
 template Tpl(T) { ... }
 ---

 --- myprogram.d
 using mylibrary;

 class MyClass { ... }

 instance Tpl(MyClass) TplMyClass; // Fails!!!
 ---

    That's what Walter seems to be saying. That the instantiation fails
 because MyClass is not visible in mylibrary.d. And that's what I have a
 problem with.


Anything passed as a template argument *is* visible.
Aug 23 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> wrote in message
news:ak3fd7$2dhu$1 digitaldaemon.com...

    So you can't really use templates taken from a library with


user-defined

 types unless those user defined types are already known to the library?


Yes you can, if you pass the user defined type as a template argument.



    I know you don't like forward declarations, but they might be warranted
 in the case of templates:

 template Tpl(T) {
   exists void func(T); // forward declaration...
   void anotherfunc(T t) {
     func(t);
   }
 }

    This would allow you to eliminate all problems with dependent names.
 It'll also allow the compiler to do even better error messages for invalid
 instantiations. In a way, you can consider this as compile-time contracts
 for templates.


You can do things like:

    template Tpl(T)
    {
            T.func(t);
    }

Won't that fit the bill?
Aug 23 2002
prev sibling next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
This sounds like Pascal declaration syntax.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ak0rom$app$3 digitaldaemon.com...

 "Mac Reiter" <Mac_member pathlink.com> wrote in message
 news:ak09pv$1b4k$1 digitaldaemon.com...

 3. It might be useful to have some way to say that some template


 parameters are

 "like" or "derived from" other template parameters:

 template Cage(Base, Derived like Base) {/*whatever*/}

 Then at instantiation:

 inst Cage(Bird, Cockateel);    // OK, assuming Cockateel derives from




Bird

 inst Cage(Bird, Bird);         // OK
 inst Cage(Bird, Collie);       // Error - Collie does not derive from




Bird

 inst Cage(Bird, Animal);       // Error - inheritance order is backwards

 I'm not sure how useful this is in practice.  I know Eiffel has a




similar

 system, and Bertrand Meyer gets really excited about it, but I was never


 certain

 that I saw the benefit of this over using Base*s and letting vtables


 handle it.

 4. I would really like constrained genericity.  Similar to the above,




but

 when

 you say a parameter is "like" some base class, the base class doesn't




need

 to be

 another parameter to the template.

 template Calculator(T like NUMERIC) {/*whatever*/}

 In this case, NUMERIC is basically an interface.  The standard argument


 against

 this is that if someone tries to instantiate the template with a class


 that is

 not NUMERIC, something will fail when Calculator tries to use one of the


 NUMERIC

 members.  But it is possible (even if unlikely) that a non-NUMERIC class


 could

 accidentally implement enough of NUMERIC to let it work, but not work




the

 way

 Calculator expects.  Calculator is a bad example of this, since anyone


 providing

 NUMERIC-style members probably is doing numerical work -- but for other
 templates and other interfaces, the issue is not as clear.  The other


 benefit is

 self-documentation.  By placing it in the code, the developer makes it


 clear

 what he/she is requiring for the template parameter.  It becomes part of


 the

 contract.


 It occurs to me that this does fit in with the D template syntax:

     template Calculator(T : NUMERIC) { ... }

 means that T can be either NUMERIC or a class derived from NUMERIC (if
 NUMERIC is a class or interface). Your case 3 would be:

     template Cage(B, D : B) {/*whatever*/}

 which would constrain D to be the same as B or derived from B.
Aug 22 2002
parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <ak36u4$23sj$1 digitaldaemon.com>, Sean L. Palmer says...

This sounds like Pascal declaration syntax.

Sean


Actually taken from Eiffel, at least when I mentioned it.  It does happen to be
the same syntax as Pascal's:

var
I : INTEGER;

I suppose that for UML people, some simulation of the inheritance arrow might be
better:

template Calc(T=>NUMERIC)
or
template Calc(T->NUMERIC)

I don't know if this causes lexing/parsing problems or not.  It is about as
close as I can think of to UML's method of showing that T inherits from NUMERIC.

I personally don't have a problem with the ':' syntax and its simularity to
Pascal.  I suppose it might cause problems for Delphi programmers, but anyone
used to any older form of Pascal is going to be going through so many mental
contortions anyway that they probably wouldn't even notice it.  Even if they
did, it is still vaguely appropriate:

I : INTEGER;

means that I "is an" INTEGER.

T : NUMERIC

means that T "is a" NUMERIC.  It just happens to be the case that in OOP the "is
a" relationship is much more flexible than it was in Pascal...

I'm cool with almost any form, as long as it provides compile time type
constraints for the template parameters.

Mac

(the following is for reference...)

"Walter" <walter digitalmars.com> wrote in message
news:ak0rom$app$3 digitaldaemon.com...

 "Mac Reiter" <Mac_member pathlink.com> wrote in message
 news:ak09pv$1b4k$1 digitaldaemon.com...




[clip]

 It occurs to me that this does fit in with the D template syntax:

     template Calculator(T : NUMERIC) { ... }

 means that T can be either NUMERIC or a class derived from NUMERIC (if
 NUMERIC is a class or interface). Your case 3 would be:

     template Cage(B, D : B) {/*whatever*/}

 which would constrain D to be the same as B or derived from B.
Aug 22 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Thu, 22 Aug 2002 18:25:46 +0000 (UTC) Mac Reiter <Mac_member pathlink.com> 
wrote:


 I : INTEGER;
 
 means that I "is an" INTEGER.
 
 T : NUMERIC
 
 means that T "is a" NUMERIC.  It just happens to be the case that in OOP the 


"is

 a" relationship is much more flexible than it was in Pascal...


Yes, exactly. Being a hardcore Pascal fan once, I must admit that I like this 
syntax partially
because it reminds me of good old TP days... =)
Aug 22 2002
parent "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374909701815972 news.digitalmars.com...


 T : NUMERIC


 Yes, exactly. Being a hardcore Pascal fan once, I must admit that I like


this

 syntax partially
 because it reminds me of good old TP days... =)


   He he... I've come to like it better than the C/C++ syntax. Much clearer,
much less ambiguous, and it rationalizes the use of type expressions, by
making them look exactly the same wether you're casting, or specifying a
template argument, or declaring a variable of such type.

Salutaciones,
                       JCAB
Aug 22 2002
prev sibling parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 It occurs to me that this does fit in with the D template syntax:
 
     template Calculator(T : NUMERIC) { ... }
 
 means that T can be either NUMERIC or a class derived from NUMERIC (if
 NUMERIC is a class or interface). Your case 3 would be:
 
     template Cage(B, D : B) {/*whatever*/}
 
 which would constrain D to be the same as B or derived from B.


I could see somebody wanting to do something like this:

template List(X) {
     class List {...};
};
template Thingy(A, List(A).List) {...};

However, since we can't refer to template instances that way - we have 
to instantiate them explictly - I don't see any way to do this with the 
current template syntax.  Do you have any ideas how?
Aug 22 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D655282.5030402 deming-os.org...

 I could see somebody wanting to do something like this:

 template List(X) {
      class List {...};
 };
 template Thingy(A, List(A).List) {...};

 However, since we can't refer to template instances that way - we have
 to instantiate them explictly - I don't see any way to do this with the
 current template syntax.  Do you have any ideas how?


I could see doing that with:

template Thingy(A,  instance List(A).List) {...};
Aug 23 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ak757j$dr2$1 digitaldaemon.com...

 "Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D655282.5030402 deming-os.org...

 I could see somebody wanting to do something like this:

 template List(X) {
      class List {...};
 };
 template Thingy(A, List(A).List) {...};

 However, since we can't refer to template instances that way - we have
 to instantiate them explictly - I don't see any way to do this with the
 current template syntax.  Do you have any ideas how?


 I could see doing that with:

 template Thingy(A,  instance List(A).List) {...};


Why would you need to pass on a completely dependent type as a seperate type
parameter?

template Thingy(A) {
  alias  ListType instance List(A).List;
  ....
}

But how could you write a template with two arguments, one partially
dependent on the other? Is this OK? :

template AdvancedList(E, F) { ... }

template Thingy(A, B : instance AdvancedList(A, C)) { ... }

Please correct me if wrong. I was intended to create a template whose second
type argument is an instance of AdvancedList,  with the restriction that
this AdvancedL:ist instance should be instatiated with the "A" type as the
first type parameter. I supposed that there is no type named "C".

Another thing. Quoting template.html:

template Bar(D, D : D[]) { }

Is this valid?! You should give unique names to your type parameters. The
first type parameter is called "D", and the second?
Also I find bewildering the syntax:
D : D[]
Does this mean that the second type parameter "D" is an array composed of
elements of its own type? (Infinite recursion)

Yours,
Sandor
Aug 26 2002
parent "Walter" <walter digitalmars.com> writes:
"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:akdcn1$1rs5$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 Why would you need to pass on a completely dependent type as a seperate


type

 parameter?


As a template specialization of a more general template.


 But how could you write a template with two arguments, one partially
 dependent on the other? Is this OK? :

 template AdvancedList(E, F) { ... }

 template Thingy(A, B : instance AdvancedList(A, C)) { ... }


Yes.


 template Bar(D, D : D[]) { }

 Is this valid?! You should give unique names to your type parameters. The
 first type parameter is called "D", and the second?
 Also I find bewildering the syntax:
 D : D[]
 Does this mean that the second type parameter "D" is an array composed of
 elements of its own type? (Infinite recursion)


Hmm. Perhaps I goofed <g>.
Aug 26 2002
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
Hmmm .... this "namespace" approach to templates leans toward ease of
implementation, which is good.

Is there any way to do non-type template parameters?

template VectorNamespace(T, int S)
{
    class Vector
    {
        T[S] array;
    }
}

Also, I think that you should be able to do multiple specialization:

template Foo(T) { ... }
template Foo(T : int, float, double) { ... }

-Craig
Aug 21 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Craig Black" <cblack ara.com> wrote in message
news:ak0h9n$1p37$1 digitaldaemon.com...

 Hmmm .... this "namespace" approach to templates leans toward ease of
 implementation, which is good.


It's a bit of an adjustment, but in the end I think it is superior.


 Is there any way to do non-type template parameters?

 template VectorNamespace(T, int S)
 {
     class Vector
     {
         T[S] array;
     }
 }


Not directly. It can be done indirectly as part of a type, or as a class
member where the class is passed as a type parameter. I thought a lot about
this, and decided that non-type parameters were rare, but added a lot of
complexity to the parameters, so they weren't worth supporting directly.


 Also, I think that you should be able to do multiple specialization:

 template Foo(T) { ... }
 template Foo(T : int, float, double) { ... }


That can be faked using two templates, one instantiating the other.
Aug 21 2002
parent reply Mac Reiter <Mac_member pathlink.com> writes:
 Is there any way to do non-type template parameters?

 template VectorNamespace(T, int S)
 {
     class Vector
     {
         T[S] array;
     }
 }


Not directly. It can be done indirectly as part of a type, or as a class
member where the class is passed as a type parameter. I thought a lot about
this, and decided that non-type parameters were rare, but added a lot of
complexity to the parameters, so they weren't worth supporting directly.


 Also, I think that you should be able to do multiple specialization:

 template Foo(T) { ... }
 template Foo(T : int, float, double) { ... }


That can be faked using two templates, one instantiating the other.


It is entirely possible that my current QWERTY -> DVORAK immersion retraining is
just consuming too much of my mental flexibility quotient, but I suspect that
some examples may be necessary to illustrate these solutions.  This could go on
a page similar to your "Converting C to D" and "Converting C++ to D", where you
could show the C++ methodology and then the corresponding D methodology.

Mac
Aug 21 2002
parent "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak0m6l$2jt5$1 digitaldaemon.com...

 It is entirely possible that my current QWERTY -> DVORAK immersion


retraining is

 just consuming too much of my mental flexibility quotient, but I suspect


that

 some examples may be necessary to illustrate these solutions.  This could


go on

 a page similar to your "Converting C to D" and "Converting C++ to D",


where you

 could show the C++ methodology and then the corresponding D methodology.


You're quite right.
Aug 21 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
It would also be real nice if version() statements inside the template could
access the supplied actual template parameters.

template Foo(T)
{
  version(T.class.string == "int")
  {
     // do int thingy
  }
  else
  {
    // do generic thingy
  }
}

This can be simpler than specialization and is something I sorely miss in
C++.

Sean

"Craig Black" <cblack ara.com> wrote in message
news:ak0h9n$1p37$1 digitaldaemon.com...

 Hmmm .... this "namespace" approach to templates leans toward ease of
 implementation, which is good.

 Is there any way to do non-type template parameters?

 template VectorNamespace(T, int S)
 {
     class Vector
     {
         T[S] array;
     }
 }

 Also, I think that you should be able to do multiple specialization:

 template Foo(T) { ... }
 template Foo(T : int, float, double) { ... }

 -Craig
Aug 22 2002
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ak36kl$23os$1 digitaldaemon.com...

 It would also be real nice if version() statements inside the template


could

 access the supplied actual template parameters.

 template Foo(T)
 {
   version(T.class.string == "int")
   {
      // do int thingy
   }
   else
   {
     // do generic thingy
   }
 }

 This can be simpler than specialization and is something I sorely miss in
 C++.


Yes, I've been thinking about that. It is a good idea, but there are many
ways to do it.
Aug 23 2002
prev sibling next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Wed=2C 21 Aug 2002 00=3A56=3A13 -0700 =22Walter=22
=3Cwalter=40digitalmars=2Ecom=3E wrote=3A

=3E www=2Edigitalmars=2Ecom=2Ftemplate=2Ehtml
=3E 
=3E Notice how short it is =3Cg=3E=2E Ok=2C what did I miss=3F

It's okay=2C but I think it could provide some more syntactic sugar=2E
It would be much better if we don't need to write a separate instantiation
for every template used in the program=2E Some in-place syntax would
be better=2E Something like this=3A

=09template Container=28T=29
=09{
=09=09class Stack
=09=09{
=09=09=09private T=5B=5D pile=3B
=09=09=09
=09=09=09void push=28T x=29
=09=09=09{=09
=09=09=09=09pile ~=3D x=3B
=09=09=09}

=09=09=09T pop=28=29
=09=09=09{
=09=09=09=09T x =3D pile=5Bpile=2Elength - 1=5D=3B
=09=09=09=09pile=2Elength =3D pile=2Elength - 1=3B
=09=09=09=09return x=3B
=09=09=09}
=09=09}
=09}

=09Container=28int=29=2EStack s=3B

This is to avoid cluttering the namespace with continuous lists of
instantiations =28which is going to happen with any large program
using templates extensively=29=2E
Aug 21 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
I hear you, but I want to try it with explicit instantiation names first.
The reason is because I find templated code with lots of implicit
instantiations to be totally unreadable.


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374899452836458 news.digitalmars.com...
Container(int).Stack s;
This is to avoid cluttering the namespace with continuous lists of
instantiations (which is going to happen with any large program
using templates extensively).
Aug 21 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
It's still explicit, it just isn't a declaration by itself, it's part of
another declaration or even part of a statement.  Legal wherever a typespec
or field reference is legal.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ak0qju$37o$1 digitaldaemon.com...

 I hear you, but I want to try it with explicit instantiation names first.
 The reason is because I find templated code with lots of implicit
 instantiations to be totally unreadable.


 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374899452836458 news.digitalmars.com...
 Container(int).Stack s;
 This is to avoid cluttering the namespace with continuous lists of
 instantiations (which is going to happen with any large program
 using templates extensively).
Aug 22 2002
parent reply "Walter" <walter digitalmars.com> writes:
I think that can work if it is prefaced by the keyword "instance".

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ak36qj$23r4$1 digitaldaemon.com...

 It's still explicit, it just isn't a declaration by itself, it's part of
 another declaration or even part of a statement.  Legal wherever a


typespec

 or field reference is legal.

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:ak0qju$37o$1 digitaldaemon.com...

 I hear you, but I want to try it with explicit instantiation names




first.

 The reason is because I find templated code with lots of implicit
 instantiations to be totally unreadable.


 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374899452836458 news.digitalmars.com...
 Container(int).Stack s;
 This is to avoid cluttering the namespace with continuous lists of
 instantiations (which is going to happen with any large program
 using templates extensively).
Aug 23 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Fri=2C 23 Aug 2002 20=3A40=3A53 -0700 =22Walter=22
=3Cwalter=40digitalmars=2Ecom=3E wrote=3A

=3E I think that can work if it is prefaced by the keyword =22instance=22=2E

Great! So=2C we could write=3F

=09instance Container=28double=29=2Edeque q=3B
Aug 24 2002
parent "Walter" <walter digitalmars.com> writes:
Yes.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374924726702083 news.digitalmars.com...
On Fri, 23 Aug 2002 20:40:53 -0700 "Walter" <walter digitalmars.com> wrote:


 I think that can work if it is prefaced by the keyword "instance".


Great! So, we could write?

instance Container(double).deque q;
Aug 24 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374899452836458 news.digitalmars.com...

Container(int).Stack s;
This is to avoid cluttering the namespace with continuous lists of
instantiations (which is going to happen with any large program
using templates extensively).


I forgot to mention that has syntax parsing problems, too. How about this:

instance Container(int).Stack s;

?
Aug 21 2002
next sibling parent Joel Lucsy <jjlucsy ameritech.net> writes:
"Walter" <walter digitalmars.com> wrote in
news:ak0t51$k2o$1 digitaldaemon.com: 


 
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374899452836458 news.digitalmars.com...

Container(int).Stack s;
This is to avoid cluttering the namespace with continuous lists of
instantiations (which is going to happen with any large program
using templates extensively).


 
 I forgot to mention that has syntax parsing problems, too. How about
 this: 
 
 instance Container(int).Stack s;
 
 ?
 
 


Just to throw it out:
    	Stack s from instance of Container(int);
or:
    	Stack s from instance Container(int);
or:
    	Stack s instance Container(int);
or:
    	Stack s in Container(int);
Aug 21 2002
prev sibling parent Pavel Minayev <evilone omen.ru> writes:
On Wed, 21 Aug 2002 13:10:47 -0700 "Walter" <walter digitalmars.com> wrote:


 I forgot to mention that has syntax parsing problems, too. How about this:
 
 instance Container(int).Stack s;
 
 ?


This is also fine!
Aug 21 2002
prev sibling next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
One possible problem with the static but multiply nameable nature of templates
is that person A working on Foo.d might instantiate (to pick a template name at
semi-random) Container(int) as FooCont.  Person B might make Container(int) as
BarCont in Bar.d.  If the Container template has any variables in it, they would
be somewhat like global variables.  The problem is, A would think they had their
own copy in FooCont and B would think theirs was safe in BarCont.

Because of the description, *if* they know about each other, then they will know
that these global variables are not "safe".  But a Container(int) is (for sake
of argument) a common thing to make, and anyone could make one at any time.  You
most likely would not know that someone, perhaps a library writer, had already
instantiated Container(int).  Since you can't ever know who else might be
changing the variables inside your template instance, you can't really ever
safely use those variables.  If you are single threaded, you arguably could use
the variables as long as you never did anything that would cause code outside of
your control to execute, but that becomes more and more difficult as code
becomes more object oriented.

What problems would be caused by having each "equivalently parameterized"
instance of a template manage their own variables?  The
classes/structs/enums/etc could still be shared, so that person A could pass a
reference to a FooCont.SomeClass object into person B's code, where it is used
as a BarCont.SomeClass object.  Of course, if you do that, the FooCont.SomeClass
object may be surprised when values of the Container(int) variables change when
it moves into BarCont territory...

Maybe template variables should just be outlawed?  "const"s are fine, since
nobody can change them, and they are extremely useful for configuration options.
But variables just seem to be dangerous and seem to risk violating encapsulation
expectations.

Mac
Aug 21 2002
parent "Walter" <walter digitalmars.com> writes:
The problem only occurs with template variables. It's really the same issue
as global variables in general, they have their uses but should normally be
avoided. I can see cases where they would be useful, for example, to hold a
handle to a globally shared resource.

"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak0pde$2s5j$1 digitaldaemon.com...

 Maybe template variables should just be outlawed?  "const"s are fine,


since

 nobody can change them, and they are extremely useful for configuration


options.

 But variables just seem to be dangerous and seem to risk violating


encapsulation

 expectations.
Aug 21 2002
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in news:ajvgsb$6gt$1
 digitaldaemon.com:


 www.digitalmars.com/template.html
 
 Notice how short it is <g>. Ok, what did I miss?
 
 


Templates. Cool!


Does the statement "Semantic analysis is not done until 
instantiated." mean that the tempate will pick up variables 
and functions in the scope in which it is instantiated?

// File: temp.d
template Foo(T)
{
  bit Bar(T a)
  {
    return a < BorgConst;
  }
}

// File alpha.d
import temp;

int BorgConst = 12;

in Foo(int) here;

here.Bar(5); // returns true

If this is true it would seem to perhaps be at odds with 
this statement "Multiple instantiations of a TemplateDeclaration 
with the same TemplateParameterList all will refer to the same 
instantiation."

Files alpha.d and bravo.d are in the same project.

// File bravo.d
int BorgConst = 4;

in Foo(int) here;

here.Bar(5); // returns false ?
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns9271999977E06patcodemooncom 63.105.9.61...

 Does the statement "Semantic analysis is not done until
 instantiated." mean that the tempate will pick up variables
 and functions in the scope in which it is instantiated?


Nope. The only thing it will pick up from the instantiation scope is the
template argument types.


 // File: temp.d
 template Foo(T)
 {
   bit Bar(T a)
   {
     return a < BorgConst;
   }
 }

 // File alpha.d
 import temp;

 int BorgConst = 12;

 in Foo(int) here;

 here.Bar(5); // returns true

 If this is true it would seem to perhaps be at odds with
 this statement "Multiple instantiations of a TemplateDeclaration
 with the same TemplateParameterList all will refer to the same
 instantiation."


Correct, which is one reason why it is false (and your example will fail to
compile with a "BorgConst undefined" error). Templates are instantiated in
the scope in which the template is declared. This avoids the whole C++ mess
of "non-dependent names" versus "dependent names" and their subtly different
lookup schemes.

Clean separation between syntax and semantics is what makes this easy to do
in D, and nearly impossible in C++.
Aug 21 2002
parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:ak0uas$rqn$1 digitaldaemon.com: 


 
 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns9271999977E06patcodemooncom 63.105.9.61...

 Does the statement "Semantic analysis is not done until
 instantiated." mean that the tempate will pick up variables
 and functions in the scope in which it is instantiated?


 
 Nope. The only thing it will pick up from the instantiation scope is
 the template argument types.
 


Have you see C++ template usage like this?

template<class T>
class Foo
{
  public:
  int addToClassFunc(int param)
  {
    T* pT = static_cast<T*>(this);
    
    return pT->classFunc() + param;
  }
}

class Bar : public A, public Foo<Bar>
{
  int classFunc()
  {
    return 12;
  }
};

Bar b;
b.addToClassFunc(5); // return 15


Of course D doesn't have multiple inheritance.
But do you really need it to be able to do 
functionality aggregation like the C++ example 
above?
Aug 22 2002
next sibling parent reply Patrick Down <pat codemoon.com> writes:
What about this...

template Foo(this : T) // use this to bind it to a class
{
  int addClassFunc(int a)
  {
    return this.localFunc() + a;
  }
}

class Bar
{
  in Foo(Bar) mixin;

  int localFunc()
  {
    return 12;
  }
}
Aug 22 2002
parent "Walter" <walter digitalmars.com> writes:
Offhand I don't see why that shouldn't work. -Walter

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns927264FD45DF2patcodemooncom 63.105.9.61...

 What about this...

 template Foo(this : T) // use this to bind it to a class
 {
   int addClassFunc(int a)
   {
     return this.localFunc() + a;
   }
 }

 class Bar
 {
   in Foo(Bar) mixin;

   int localFunc()
   {
     return 12;
   }
 }
Aug 22 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
No, I haven't. But perhaps it can be done with interfaces.

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns927255B703EE3patcodemooncom 63.105.9.61...

 Have you see C++ template usage like this?

 template<class T>
 class Foo
 {
   public:
   int addToClassFunc(int param)
   {
     T* pT = static_cast<T*>(this);

     return pT->classFunc() + param;
   }
 }

 class Bar : public A, public Foo<Bar>
 {
   int classFunc()
   {
     return 12;
   }
 };

 Bar b;
 b.addToClassFunc(5); // return 15


 Of course D doesn't have multiple inheritance.
 But do you really need it to be able to do
 functionality aggregation like the C++ example
 above?
Aug 22 2002
parent Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in news:ak2umn$1qcd$1
 digitaldaemon.com:


 No, I haven't. But perhaps it can be done with interfaces.
 


It's used extensivly by microsoft in ATL.  It's one of those C++
this where I find the C++ template syntax bad, but the general
idea has merit.
Aug 22 2002
prev sibling next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Walter" <walter digitalmars.com> wrote in message
news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html

 Notice how short it is <g>. Ok, what did I miss?


I would like the ability to pass constants such as literals and function
pointers. For example, a smart-pointer could have a special free function
given as argument.

A feature I have been missing in C++, is the ability to have conditional
compilation based on the concrete types. This would be useful if eg. 95% of
the template code is the same, but the rest needs to be different. In some
cases, it would also allow the template to provide a more efficient
implementation for a specific type.

Regards,
Martin M. Pedersen
Aug 21 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ak0udv$sch$1 digitaldaemon.com...

 For example, a smart-pointer could have a special free function > given as


argument.

It reminds me: Smart pointers would need the ability to redefine the member
operator. Is it feasible in D?

Regards,
Martin M. Pedersen
Aug 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ak108p$18il$1 digitaldaemon.com...

 It reminds me: Smart pointers would need the ability to redefine the


member

 operator. Is it feasible in D?


In a garbage collected language, is there a need for smart pointers?
Aug 21 2002
next sibling parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Walter" <walter digitalmars.com> wrote in message
news:ak147n$273f$1 digitaldaemon.com...

 In a garbage collected language, is there a need for smart pointers?


I'm not sure, considering try/catch/finally. But there are lots of C APIs
out there returning POD structures with special free functions.
fopen()/fclose() and opendir()/closedir() are simple examples of this, MAPI
with MAPIFreeBuffer() is another. Even if D itself is garbage collected,
many applications written in D will use such APIs, and GC will not solve all
their problems. If I was to use the GC to clean up, I would need something
like:

    interface Free { void special_free(void *); }

    template TSmartPointer(T, F : Free)
    {
       class SmartPointer {
           this(T* t) { m_t = t; }
           ~this() { F.special_free(m_t); }
          T* m_t;
       }
    }

    class CloseFile: Free
    {
        void special_free(void* fp) { fclose((FILE*)fp); } // I don't check
the result, I know - slap me.
     }

    instance TSmartPointer fileClosing(FILE, CloseFile);

    FILE* fp = fopen("name", "r");
    fileClosing.SmartPointer closeÍt = new fileClosing.SmartPointer(fp);
    ... now access it using fp

Clearly, that is too tedious. try/finally would probably be a better
solution...

Regards,
Martin M. Pedersen
Aug 21 2002
prev sibling parent reply "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ak147n$273f$1 digitaldaemon.com...


 In a garbage collected language, is there a need for smart pointers?


   Butofcourse. Smart pointers and memory management don't necessarily have
to be related at all. The fact that most smart pointers are only used to
manage memory doesn't mean that has to be the case. For example, I have a
buncha smart pointers that manage file access. They are "smart" because they
will manage the ownership of the file, and "pointers" because they emulate a
pointer to an interface with members that perform operations on the file.

   The way you have D set up, you just can't do this, anyway, which I still
think is a real pity and the thing that kills D (alongside with Java) for
me. Ahem... Not that I'm not duly impressed...

Salutaciones,
                       JCAB
Aug 21 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> wrote in message
news:ak1ht1$753$1 digitaldaemon.com...

    The way you have D set up, you just can't do this, anyway, which I


still

 think is a real pity and the thing that kills D (alongside with Java) for
 me. Ahem... Not that I'm not duly impressed...


Even if you don't use D, I've found your comments about it to be very
valuable. Are you sure that all the other neat stuff in D doesn't tempt you?
<g>
Aug 21 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ak1p2n$1ben$1 digitaldaemon.com...


 Even if you don't use D, I've found your comments about it to be very
 valuable.


   Thanx.


 Are you sure that all the other neat stuff in D doesn't tempt you?


   Yes, it does. But not enough to use it. It does tempt me to try and make
my own language, thoguh ;-)

Salutaciones,
                       JCAB
Aug 22 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I've been thinking along the same lines.  I'd like to see what kind of
language you'd come up with.  I really liked what I saw in Yoritz language,
and NVIDIA Cg.  Something with simplified memory management and designed to
be implemented using SIMD.  I have a lot of vague ideas and no time to
solidify them.

I'm likely to completely ditch C compatibility if I make a language, though.
Too much baggage.  I'd make it able to link with C but not syntactically
compatible.

Sean

"Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> wrote in message
news:ak3ami$286g$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:ak1p2n$1ben$1 digitaldaemon.com...


 Even if you don't use D, I've found your comments about it to be very
 valuable.


    Thanx.


 Are you sure that all the other neat stuff in D doesn't tempt you?


    Yes, it does. But not enough to use it. It does tempt me to try and


make

 my own language, thoguh ;-)

 Salutaciones,
                        JCAB
Aug 23 2002
parent "Juan Carlos Arevalo Baeza" <jcab JCABs-Rumblings.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ak5pq2$210p$1 digitaldaemon.com...


 I've been thinking along the same lines.  I'd like to see what kind of
 language you'd come up with.  I really liked what I saw in Yoritz


language,

 and NVIDIA Cg.  Something with simplified memory management and designed


to

 be implemented using SIMD.  I have a lot of vague ideas and no time to
 solidify them.


   :-) Yes, I know the feeling. And I would really like to compare ideas,
too. Hmmm... You know what? I think I'm going to start a little discussion
list of my own on my server, to discuss this kind of thing. I'm taking the
liberty of subscribing you, Sean. Anyone else interested, go here (hope this
works) or drop me email:

http://lists.jcabs-rumblings.com/listinfo.cgi/npl-jcabs-rumblings.com

   For short, the language I have in mind is:

- Small C-style run-time model and language kernel. This means bit & byte
manipulation, basic memory address algebra, variables & functions... With
room for platform-specific additions, of course, like I/O port access, etc.

- Extremely simple parser (much simpler than even D). This is, I believe, my
most outrageous idea. If it works, that is.

- Configurable semantics for high extensibility. Ability to create language
primitives and sub-languages by programming the mapping of them into the
kernel.

- Compile-time execution model.

- Standard library including higher-level stuff like GC, which would be
optional to use.


 I'm likely to completely ditch C compatibility if I make a language,


though.

 Too much baggage.  I'd make it able to link with C but not syntactically
 compatible.


   I'm completely ready to ditch compatibility. I'm also working on a C/C++
parser to ease converting source code.

Salutaciones,
                       JCAB
Aug 23 2002
prev sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
Minor semantic point, but the more general case of smart resource managers has
begun to be named "smart handles".  Since pointers are inextricably tied up with
memory in so many developers minds, a change in name (while technically
irrelevant) helps us to remember non-memory resources like files, mutexes,
ports, etc.

This has been a major contention with garbage collected systems for one of my
coworkers.  My current stance is that garbage collection solves the 99% rule
with 1% of the effort.  Because D is a pragmatic language, rather than an
academic one, it also supplies two important resource management capabilities:

1. explicit delete
2. finally clauses

Most garbage collected systems refuse to allow *any* way to guarantee when an
object will be freed/finalized.  Explicit deletes at least allow you as much
control as you had in C.  It does not provide the automatic scoping destructor
behavior, however, so you have to use 'finally' clauses.  If you have a resource
that you absolutely have to clear up before you exit a scope, build a finally
clause and clean it up in there.  This does take a bit more effort, but only for
the rarer case of non-memory resources, which you generally end up writing a lot
of exception handling code for anyway.  Non-memory resources are *much* more
likely to be inaccessible, or to exhibit some form of error or other exception
while you are using them, so you have to be careful with them no matter how much
support the language provides.  The addition of a finally clause to a scope that
is already laden with error handling code is not too much of a price to pay, and
actually substantially decreases the programming load from most code that I have
seen.

Having said all of that, it would be nice to have the ability to have a
reference counted object.  I would not want it for all objects, because the
speed penalty of reference counting *all* of your pointers is rather severe
(Nothing like a big heavy book on Garbage Collection to clear out any
misconceptions you have...).  However, for specific things, like files, mutex
locks, ports, etc, it might be nice to have a syntax like:

counted class SerialPort
{
}

This would cause the compiler to add a thread-safe reference counting mechanism
to SerialPort.  Creation, assignment, etc would then have to maintain the
reference count invariant and delete the object as soon as the reference count
hit 0.  It does add special handling to objects of this type, as well as
references/pointers to this type, but I don't think it causes any problems for
separate lexing/parsing.  I think it just requires that the code generator be
able to access the symbol table to know that this object is counted, and the
code generator has to have access to the symbol table anyway...

For basic "allocation is acquisition" style programming, this works great.
Reference comes into being at top of scope, resource is acquired in constructor
and ref count goes up to 1.  At the bottom of the scope, the reference
disappears, the ref count goes down to 0, and the object is deleted, just like
it would have been in C++.  What's really nice is that you can make the thing
inside a function and return it back out.  The process of copying the
pointer/reference into the return value increases the reference count.  The
object will live as long as anyone is using it, and die the instant the last
user lets go.  

Reference counting is notoriously difficult to do in libraries or source code,
because the compiler can perform optimizations around scope boundaries that can
invalidate the reference counting invariant.  If that ever happens, the whole
scheme explodes (you either leak something or free it too soon).  But if the
compiler did the reference counting, it could ensure logically correct reference
counting, even if it took shortcuts for efficiency.  For example, if a local
object was being returned, the compiler knows that one reference existed inside
the function and that one reference will exist outside the function.
Technically, it should increase the reference when it copies the pointer into
the return value, and then decrease the reference when it unrolls the stack and
loses the local variable.  However, it could simply not touch the reference
count at all, and be completely correct in its result.  It would know this
because it was trading 1 local reference for 1 return reference.  A similar
behavior occurs at the point where the return value for the function is assigned
into a variable, and the same optimization can be performed.

By providing a selective ability to use reference counted classes, and by making
it require the extra keyword, D could provide additional flexibility without
adding danger to the new users.  Until you were experienced enough to know what
'counted' was for and why you would want to use it, you would simply leave all
your classes GC'ed, which is logically correct, even if it might introduce
longer pauses before resources were freed.  You *don't* want to go to all
reference counted classes, because the speed penalties are bad, and more
importantly, because reference counting cannot remove cyclic systems.

A.next = B;
B.next = C;
C.next = B;  // made a loop with B and C
// do something
A.next = NULL;
// No way to reach B or C, but each still has a reference count of 1
// because of the loop.

Mark and sweep, which D currently uses, has absolutely no problem whatsoever
with cyclic systems, and (depending on the implementation of the algorithm) can
provide more tunable memory management CPU consumption than reference counting.
That makes GC a much better general purpose solution than refcounting.

Sorry, that was more rambling than I intended, and probably more than this
audience needed...
Mac

In article <ak1ht1$753$1 digitaldaemon.com>, Juan Carlos Arevalo Baeza says...

"Walter" <walter digitalmars.com> wrote in message
news:ak147n$273f$1 digitaldaemon.com...


 In a garbage collected language, is there a need for smart pointers?


   Butofcourse. Smart pointers and memory management don't necessarily have
to be related at all. The fact that most smart pointers are only used to
manage memory doesn't mean that has to be the case. For example, I have a
buncha smart pointers that manage file access. They are "smart" because they
will manage the ownership of the file, and "pointers" because they emulate a
pointer to an interface with members that perform operations on the file.

   The way you have D set up, you just can't do this, anyway, which I still
think is a real pity and the thing that kills D (alongside with Java) for
me. Ahem... Not that I'm not duly impressed...

Salutaciones,
                       JCAB
Aug 22 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Your comments on smart handles in D explain it better than I have.
Mind if I plagairize it a bit?

I also
suspect you are right in that the only way to do reference counting right is
to clue the compiler in and have the compiler manage it.
Aug 22 2002
parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <ak32sg$1v7v$1 digitaldaemon.com>, Walter says...

Your comments on smart handles in D explain it better than I have.
Mind if I plagairize it a bit?


I would be honored.


I also
suspect you are right in that the only way to do reference counting right is
to clue the compiler in and have the compiler manage it.


I know that 'counted' would increase the complexity of the compiler, which you
have been trying to avoid, but I think it could be done without too much
additional effort.  (I am not, however, familiar with writing compilers, so my
assumptions could be vastly incorrect)  It would certainly take less effort to
get it right (ignoring issues of "completely optimized" for the time being)
inside the compiler than it does outside.

Mac
Aug 22 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak3agl$27qt$1 digitaldaemon.com...

 I know that 'counted' would increase the complexity of the compiler, which


you

 have been trying to avoid, but I think it could be done without too much
 additional effort.  (I am not, however, familiar with writing compilers,


so my

 assumptions could be vastly incorrect)  It would certainly take less


effort to

 get it right (ignoring issues of "completely optimized" for the time


being)

 inside the compiler than it does outside.


The complexity comes from decrementing the counts of objects going out of
scope, in the presence of exceptions. It did occur to me that if this was
supported, it would also implicitly support the people who want
deterministic destruction.
Aug 23 2002
parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <ak5rgs$23m5$1 digitaldaemon.com>, Walter says...

"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak3agl$27qt$1 digitaldaemon.com...

 I know that 'counted' would increase the complexity of the compiler, which


you


[clip]

The complexity comes from decrementing the counts of objects going out of
scope, in the presence of exceptions. It did occur to me that if this was
supported, it would also implicitly support the people who want
deterministic destruction.


Yup.  Actually, I originally started thinking about a 'scoped' keyword whose
sole purpose was to supply scoped destruction, but then I got to thinking about
the times when you might want to make a new thing and pass it out of a function,
but you still wanted its resources cleaned up as quickly as possible.  So I
started thinking about reference counting and realized that it would handle the
'scoped' behavior as a trivial case.  Made me happy...

Mac
Aug 23 2002
parent "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak5v0i$277b$1 digitaldaemon.com...

 Yup.  Actually, I originally started thinking about a 'scoped' keyword


whose

 sole purpose was to supply scoped destruction, but then I got to thinking


about

 the times when you might want to make a new thing and pass it out of a


function,

 but you still wanted its resources cleaned up as quickly as possible.  So


I

 started thinking about reference counting and realized that it would


handle the

 'scoped' behavior as a trivial case.  Made me happy...


It's pretty cool when solving one problem provides a trivial solution to an
apparently unrelated problem.
Aug 23 2002
prev sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Thu, 22 Aug 2002 15:29:07 +0000 (UTC) Mac Reiter <Mac_member pathlink.com> 
wrote:


 A.next = B;
 B.next = C;
 C.next = B;  // made a loop with B and C
 // do something
 A.next = NULL;
 // No way to reach B or C, but each still has a reference count of 1
 // because of the loop.


Note that if GC will still run on refcounted objects as well, it provides a 
solution (or sort of) -
such cases will get resolved (and destructors will be called), but not 
immediately...
Aug 22 2002
parent Mac Reiter <Mac_member pathlink.com> writes:
Thank you.  I meant to illustrate reference counting as a means of minimizing
reclamation latency, but relying on garbage collection as the final means of
ensuring correctness/completeness of de-allocation.  Somewhere along the way I
forgot to state that clearly...  Guess I ramble too much.  

I just wanted to make sure that nobody thought "Hey, reference counting gives
quick reclamation!  Why don't we just use that instead of this garbage
collection system?"  I prefer the combination so that you can take advantages of
the strengths of each system.

Mac

In article <CFN374909677284259 news.digitalmars.com>, Pavel Minayev says...

On Thu, 22 Aug 2002 15:29:07 +0000 (UTC) Mac Reiter <Mac_member pathlink.com> 
wrote:


 A.next = B;
 B.next = C;
 C.next = B;  // made a loop with B and C
 // do something
 A.next = NULL;
 // No way to reach B or C, but each still has a reference count of 1
 // because of the loop.


Note that if GC will still run on refcounted objects as well, it provides a 
solution (or sort of) -
such cases will get resolved (and destructors will be called), but not 
immediately...
Aug 22 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ak0udv$sch$1 digitaldaemon.com...

 I would like the ability to pass constants such as literals and function
 pointers. For example, a smart-pointer could have a special free function
 given as argument.


I've thought about this. Wouldn't it make sense to have an argument that is
an interface, the implementation of which has the desired special free
function?

    interface Free { void special_free(void *); }
    template Foo(T, U : Free)
    {
        ...
        U.special_free(p);
        ...
    }

    class Bar : Free
    {
        void special_free(void *p) { ... }
    }
    instance Foo(int, Bar) abc;



 A feature I have been missing in C++, is the ability to have conditional
 compilation based on the concrete types. This would be useful if eg. 95%


of

 the template code is the same, but the rest needs to be different. In some
 cases, it would also allow the template to provide a more efficient
 implementation for a specific type.


This would be a valuable feature, but there are many different ways to do
it. I haven't gone far down the path of exploring them.
Aug 21 2002
parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Walter" <walter digitalmars.com> wrote in message
news:ak119a$1ga1$1 digitaldaemon.com...

 I've thought about this. Wouldn't it make sense to have an argument that


is

 an interface, the implementation of which has the desired special free
 function?


That would do it, I think :-)


 A feature I have been missing in C++, is the ability to have conditional
 compilation based on the concrete types.


 This would be a valuable feature, but there are many different ways to do
 it. I haven't gone far down the path of exploring them.


My solution to the missing feature in C++, has sometimes been to use
overloaded functions outside the template, but I have also resorted to not
using a template at all, but auto-generate classes instead by some special
preprocessing.

Regards,
Martin M. Pedersen
Aug 21 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
Wow, one day since this was posted and all these emails.

I was wondering about this syntax sugar.

    //Where foo is an template
    import foo(int);

Then you could use all the methods like C functions.

    x = Max(a,b);

Ofcourse problems would occur when there are more then one...

    import foo(int);
    import foo(float);

But the complier could work that out.

"Walter" <walter digitalmars.com> wrote in message
news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html

 Notice how short it is <g>. Ok, what did I miss?
Aug 22 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Thu, 22 Aug 2002 18:45:44 +0800 "anderson" <anderson firestar.com.au> wrote:


 I was wondering about this syntax sugar.
 
     //Where foo is an template
     import foo(int);
 
 Then you could use all the methods like C functions.
 
     x = Max(a,b);
 
 Ofcourse problems would occur when there are more then one...
 
     import foo(int);
     import foo(float);
 
 But the complier could work that out.


Yes, just as if the function was overloaded (and any clashes like foo(int) 
declared
twice are considered errors). I like this!
Aug 22 2002
parent "anderson" <anderson firestar.com.au> writes:
I though of another extention to that idea. How about if there is a
collision (overload), the user would have to do this...

import max(int)
import max(float)

int.max(a,b);
float.max(x,y);

That way it's simular to how D handles other overloading.

PS
I haven't been able to use this newgroup for a while, my computer crashed
and I've spent several days repairing it. Darn XP.


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374907807516898 news.digitalmars.com...

 On Thu, 22 Aug 2002 18:45:44 +0800 "anderson" <anderson firestar.com.au>


wrote:

 I was wondering about this syntax sugar.

     //Where foo is an template
     import foo(int);

 Then you could use all the methods like C functions.

     x = Max(a,b);

 Ofcourse problems would occur when there are more then one...

     import foo(int);
     import foo(float);

 But the complier could work that out.


 Yes, just as if the function was overloaded (and any clashes like foo(int)
 declared
 twice are considered errors). I like this!
Aug 27 2002
prev sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
(The following message represents me thinking and typing at the same time.  It
thus flows along my stream of consciousness, and my opinions change as it
progresses.  Please read the entire post before replying...)

Since 'import' already has a meaning, and since D templates do share many
features in common with namespaces, would 'using' be a better keyword?

using foo(int);

or, to be more complete and provide more flexibility:

using template foo(int);  // moves all template members into current namespace
using foo(int).Max;       // only moves Max into current namespace

If you attempted to bring in entire multiple instantiations of the same
template, that could probably just be outlawed.  Since you would have to do the
equivalent of a scope resolution at every usage to tell the compiler what to do
(since *all* of the names would have collided), you might as well have just done
that and skipped the 'using' step.

If you brought in different pieces of the same template, but from different
instantiations:

using foo(int).Max;
using foo(double).Min;

then there would be no namespace collision, and it might be allowable.  Horribly
confusing, in the example given above, but possibly useful in some situations...

Overall, I think that the 'using template foo(int);' form would be a handy
addition for people who only needed a single instantiation of the template and
didn't want to have to precede every template member usage with 'intfoo.'.
Trying to extend the usage beyond that, however, causes more problems than it
solves.

Which leads me to my favorite solution so far, and it is even already in the
language (at least in the syntax, even if the template usage of it may not be in
the compiler yet) -- 'with'!

with foo(int)
{
x = Max(a,b);
// more stuff, obviously
}

or maybe:

with inst foo(int)
{
}

or:

inst foo(int) intfoo;
with intfoo
{
}

This saves adding another template specific keyword, explains how name
collisions will be resolved (innermost 'with' clause that contains such a member
will win), and just generally seems nice and clean to me...  That may be my
Visual Basic experience coming back to me (VB also uses 'with', and you use it a
LOT when you start getting OOPed in VB).

Mac

In article <ak2f15$179g$1 digitaldaemon.com>, anderson says...

Wow, one day since this was posted and all these emails.

I was wondering about this syntax sugar.

    //Where foo is an template
    import foo(int);

Then you could use all the methods like C functions.

    x = Max(a,b);

Ofcourse problems would occur when there are more then one...

    import foo(int);
    import foo(float);

But the complier could work that out.

"Walter" <walter digitalmars.com> wrote in message
news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html

 Notice how short it is <g>. Ok, what did I miss?
Aug 22 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
I hadn't thought of using the with, but it just might be the ticket. And no,
it doesn't work yet with templates because templates aren't implemented at
all :-( in the compiler.

"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak2tg7$1p28$1 digitaldaemon.com...

 (The following message represents me thinking and typing at the same time.


It

 thus flows along my stream of consciousness, and my opinions change as it
 progresses.  Please read the entire post before replying...)

 Since 'import' already has a meaning, and since D templates do share many
 features in common with namespaces, would 'using' be a better keyword?

 using foo(int);

 or, to be more complete and provide more flexibility:

 using template foo(int);  // moves all template members into current


namespace

 using foo(int).Max;       // only moves Max into current namespace

 If you attempted to bring in entire multiple instantiations of the same
 template, that could probably just be outlawed.  Since you would have to


do the

 equivalent of a scope resolution at every usage to tell the compiler what


to do

 (since *all* of the names would have collided), you might as well have


just done

 that and skipped the 'using' step.

 If you brought in different pieces of the same template, but from


different

 instantiations:

 using foo(int).Max;
 using foo(double).Min;

 then there would be no namespace collision, and it might be allowable.


Horribly

 confusing, in the example given above, but possibly useful in some


situations...

 Overall, I think that the 'using template foo(int);' form would be a handy
 addition for people who only needed a single instantiation of the template


and

 didn't want to have to precede every template member usage with 'intfoo.'.
 Trying to extend the usage beyond that, however, causes more problems than


it

 solves.

 Which leads me to my favorite solution so far, and it is even already in


the

 language (at least in the syntax, even if the template usage of it may not


be in

 the compiler yet) -- 'with'!

 with foo(int)
 {
 x = Max(a,b);
 // more stuff, obviously
 }

 or maybe:

 with inst foo(int)
 {
 }

 or:

 inst foo(int) intfoo;
 with intfoo
 {
 }

 This saves adding another template specific keyword, explains how name
 collisions will be resolved (innermost 'with' clause that contains such a


member

 will win), and just generally seems nice and clean to me...  That may be


my

 Visual Basic experience coming back to me (VB also uses 'with', and you


use it a

 LOT when you start getting OOPed in VB).

 Mac
Aug 22 2002
prev sibling next sibling parent Pavel Minayev <evilone omen.ru> writes:
On Thu=2C 22 Aug 2002 14=3A46=3A31 +0000 =28UTC=29 Mac Reiter
=3CMac=5Fmember=40pathlink=2Ecom=3E 
wrote=3A

=3E If you attempted to bring in entire multiple instantiations of the same
=3E template=2C that could probably just be outlawed=2E  Since you would have
to do 
the
=3E equivalent of a scope resolution at every usage to tell the compiler what
to 
do
=3E =28since *all* of the names would have collided=29=2C you might as well
have just 
done
=3E that and skipped the 'using' step=2E

I don't think it is an error=2E=2E=2E you should just get two versions of the
same 
function=2C just
if it was overloaded=3A

=09using Min=28int=29=3B
=09using Min=28double=29=3B

=09int a=2C b=3B
=09double c=2C d=3B
=09x =3D min=28a=2C b=29=3B=09=2F=2F Min=28int=29=2Emin
=09y =3D min=28c=2C d=29=3B=09=2F=2F Min=28double=29=2Emin
Aug 22 2002
prev sibling parent "anderson" <anderson firestar.com.au> writes:
Sounds good

"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ak2tg7$1p28$1 digitaldaemon.com...

 (The following message represents me thinking and typing at the same time.


It

 thus flows along my stream of consciousness, and my opinions change as it
 progresses.  Please read the entire post before replying...)

 Since 'import' already has a meaning, and since D templates do share many
 features in common with namespaces, would 'using' be a better keyword?

 using foo(int);

 or, to be more complete and provide more flexibility:

 using template foo(int);  // moves all template members into current


namespace

 using foo(int).Max;       // only moves Max into current namespace

 If you attempted to bring in entire multiple instantiations of the same
 template, that could probably just be outlawed.  Since you would have to


do the

 equivalent of a scope resolution at every usage to tell the compiler what


to do

 (since *all* of the names would have collided), you might as well have


just done

 that and skipped the 'using' step.

 If you brought in different pieces of the same template, but from


different

 instantiations:

 using foo(int).Max;
 using foo(double).Min;

 then there would be no namespace collision, and it might be allowable.


Horribly

 confusing, in the example given above, but possibly useful in some


situations...

 Overall, I think that the 'using template foo(int);' form would be a handy
 addition for people who only needed a single instantiation of the template


and

 didn't want to have to precede every template member usage with 'intfoo.'.
 Trying to extend the usage beyond that, however, causes more problems than


it

 solves.

 Which leads me to my favorite solution so far, and it is even already in


the

 language (at least in the syntax, even if the template usage of it may not


be in

 the compiler yet) -- 'with'!

 with foo(int)
 {
 x = Max(a,b);
 // more stuff, obviously
 }

 or maybe:

 with inst foo(int)
 {
 }

 or:

 inst foo(int) intfoo;
 with intfoo
 {
 }

 This saves adding another template specific keyword, explains how name
 collisions will be resolved (innermost 'with' clause that contains such a


member

 will win), and just generally seems nice and clean to me...  That may be


my

 Visual Basic experience coming back to me (VB also uses 'with', and you


use it a

 LOT when you start getting OOPed in VB).

 Mac

 In article <ak2f15$179g$1 digitaldaemon.com>, anderson says...

Wow, one day since this was posted and all these emails.

I was wondering about this syntax sugar.

    //Where foo is an template
    import foo(int);

Then you could use all the methods like C functions.

    x = Max(a,b);

Ofcourse problems would occur when there are more then one...

    import foo(int);
    import foo(float);

But the complier could work that out.

"Walter" <walter digitalmars.com> wrote in message
news:ajvgsb$6gt$1 digitaldaemon.com...

 www.digitalmars.com/template.html

 Notice how short it is <g>. Ok, what did I miss?
Aug 28 2002