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

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

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.

"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;

"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!

"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!)

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

"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 ?

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

"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;

?