From -2726183402786375182
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,aef96954609d602c
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1993-08-15 14:25:28 PST
Newsgroups: comp.std.c++
Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!wupost!csus.edu!netcom.com!rfg
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: Re: Template constraints
Message-ID: <rfgCBtK36.JMB@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <1993Aug4.182811.21153@ucc.su.OZ.AU> <rfgCBAw1F.7Hx@netcom.com> <744662863@amazon.cs.duke.edu>
Date: Sun, 15 Aug 1993 21:09:05 GMT
Lines: 78

In article <744662863@amazon.cs.duke.edu> dsb@duke.cs.duke.edu (Scott Bigham) writes:
>In article <rfgCBAw1F.7Hx@netcom.com>, Ronald F. Guilmette
>(rfg@netcom.com) suggests the following syntax extension to implement
>compile-time-enforceable template constraints:

HOLD ON A SECOND!  I just want to clarify that it was *YOU* and *YOU ALONE*
who decided to use the term "template constraints" with regard to the
rather simple suggestion that I posted (regarding a method for declaring
which members of template formal types are themselves types).

I do not wish to call what I suggested "template constraints", nor do I think
that would be at all appropriate.  That term (obviously) connotes something
far beyond (and essentially unrelated to) the issue I was attempting to
address (i.e. making it possible to *JUST* do complete syntax analysis
on template definitions... even in the total absence of any instantiations).

>>	int a;
>>
>>	template <class T { class M; }> void template_function (T arg)
>>	{
>>		T::M (a);	// declaration; not a call
>>	}
>
>An interesting proposal, and one which raises a number of questions:
>
>- Would the following (IMHO intuitive) constraints also be allowed?
>
>	template <class T { int required_data_member; }> void F(T);
>	template <class T { void required_member_fn(void); }>
>	  void G(T);
>	template <class T { void parametrized_constraint(T); }>
>	  void H(T);
>	template <class T { T another_parametrized_constraint; }>
>	  void I(T);
>	template <class T { T operator + (const T &); }> void J(T);
>	template <class T { class Multiple; class Constraints; }>
>	  void K(T);
>	template <class T: public Constrain_By_Base_Class> void L(T);
>	// and would indirect derived classes satisfy this constraint?

Let me just say that you seem to have let your imagination and creativity
get the better of you, and while your various ideas for some sort of a new
"template constraints" feature(s) may be interesting in their own right,
they bear little or no relationship to the very modest idea I had put
forward earlier to solve one very small (and very well defined) problem
relating ONLY to syntax analysis.

Indeed, I am somewhat disheartened that the follow-ups on my simple idea
for solving this one small (syntax) problem have blossomed out into
discussions of vastly more complicated "template constraint" schemes, the
soundness and/or need for which have yet to be adequately demonstrated.
I can only hope that casual observers of this thread will not mistakenly
equate simple resolutions of the syntax problem for template definitions
to these far more grandious and ambitious "template constraint" schemes.

(For some additional information relating to YOUR ambitious template
constraint scheme, I can refer you to Stroustrup's original paper on
templates, appearing in the Proceedings of the first USENIX C++ Conference,
October 1988.  In that paper, Stroustrup explains, on the first half of
page 6, why he rejected the idea of allowing the specification of detailed
constraints on template formal type arguments.  I will not say here whether
I agree or disagree with Stroustrup's analysis, but I will say that those
who would wish to revisit this design decision would be well advised to
at least familiarize themselves with Stroustrup's analysis before under-
taking to question the conclusions which he reached.)

In any case, I think it is important (especially for the X3J16 members who
follow this newsgroup) to realize that it is possible to solve the syntax
analysis problem for template definitions WITHOUT opening the door to some
vastly more complicated template constraints scheme.  The simple template
syntax problem can be (and should be) solved simply.  Other unrelated
issues can be (and should be) considered separately.

-- 

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------