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

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

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.

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

"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

On Thu, 22 Aug 2002 14:46:31 +0000 (UTC) Mac Reiter <Mac_member@pathlink.com> wrote:

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

I don't think it is an error... you should just get two versions of the same
function, just
if it was overloaded:

	using Min(int);
	using Min(double);

	int a, b;
	double c, d;
	x = min(a, b);	// Min(int).min
	y = min(c, d);	// Min(double).min

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

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... =)

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

"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