Topic: Defect report: [dcl.constexpr]/5 constexpr and templates
Author: AlbertoBarbati@libero.it (Alberto Ganesh Barbati)
Date: Tue, 6 Nov 2007 22:23:04 GMT Raw View
Gabriel Dos Reis ha scritto:
> On Tue, 6 Nov 2007, James Dennett wrote:
>
> | Gabriel Dos Reis wrote:
> | > On Mon, 5 Nov 2007, Alberto Ganesh Barbati wrote:
> | >
> | > | Such use of the term "function template" is not consistent with the use
> | > | established in clause 14 (see in particular 14.7/2, 14.7/3).
> | >
> | > however, it is coherent with 14.8 and other parts of the standard text.
Only partially. 14.8 does not apply to member functions of a class template.
> | > |
> | > | While I agree that the term "function template" might be stretched to
> | > | also include member function templates, including members of a class
> | > | template is IMHO a bit too far, and AFAIK it would be the first time in
> | > | the standard that such a thing would be made.
> | > |
> | > | Just my opinion,
> | >
> | > So, in your opinion, section 14.8 does not apply to member function
> | > templates?
> |
> | A member function template is clearly a function template,
>
> thanks goodness,
No one is disputing that. However, it's true that, for increased
clarity, in a few places of clause 14 both terms "function template" and
"member function template" are used side by side (see for example
14.6.4.1/1).
>
> | but a non-template member function of a class template may
> | or may not be, depending on perspective.
>
> More to the point, how does that affect the constexpr specification?
>
I thought I had clearly expressed that in the OP, but apparently I
wasn't. Let me recap with a code snippet:
template <class T>
class A
{
constexpr A(T x) : a(x)
{}
T a;
};
Clearly, A<int>::A() is a constexpr constructor. But what about, say,
A<std::string>::A()?
A<>::A() is a member of the class template A. It's *not* a function
template so, with the current wording, paragraph [dcl.constexpr]/5 does
not apply to it. That would make the specialization of A<std::string>::A
ill-formed.
However, I believe the intent is to ignore constexpr in that case and to
allow A<std::string>::A. Could you please confirm that?
If that is the intent, then I believe [dcl.constexpr]/5 could use a
little clarification and I provided wording for that in the OP.
I hope it's clearer now.
Regards,
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: dave@boost-consulting.com (David Abrahams)
Date: Wed, 7 Nov 2007 06:32:06 GMT Raw View
on Tue Nov 06 2007, AlbertoBarbati-AT-libero.it (Alberto Ganesh Barbati) wrote:
> Greg Herlihy ha scritto:
>>
>> On 11/5/07 11:24 AM, in article I3KXi.161547$%k.303426@twister2.libero.it,
>> "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
>>
>>>
>>> While I agree that the term "function template" might be stretched to
>>> also include member function templates, including members of a class
>>> template is IMHO a bit too far, and AFAIK it would be the first time in
>>> the standard that such a thing would be made.
>>
>> The term "template function" would be more apt in this context, since a
>> template function may refer either to an instantiation of a function
>> template or function generated by the instantiation of a class template.
>>
>> The following active defect report addresses the inconsistent function
>> template terminology in the current Standard:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2450.html#105
>>
>
> According to the resolution of DR105, the term "function template" has
> been consistently removed from the standard wording in favor of the more
> precise terms "template function" (1.3.11 and 13.3.1 and others) or
> "member functions of class templates and member function templates"
> (9.3).
Are you sure you're trying to say what you just said? I see lots of
instances of "function template" in the latest draft. "Function
template" refers to something like this:
template <class T>
T identity(T x) { return x; }
That DR is about making sure we don't use that term to mean something
like
int identity<int>(int)
> Why would you want to re-introduce the deprecated term?
There's definitely no deprecation in DR 105.
> I believe my proposal goes precisely in the direction of the resolution
> of DR105.
>
> Ganesh
>
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
>
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: AlbertoBarbati@libero.it (Alberto Ganesh Barbati)
Date: Thu, 8 Nov 2007 20:09:37 GMT Raw View
David Abrahams ha scritto:
> on Tue Nov 06 2007, AlbertoBarbati-AT-libero.it (Alberto Ganesh Barbati) wrote:
>
>> Greg Herlihy ha scritto:
>>> On 11/5/07 11:24 AM, in article I3KXi.161547$%k.303426@twister2.libero.it,
>>> "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
>>>
>>>> While I agree that the term "function template" might be stretched to
>>>> also include member function templates, including members of a class
>>>> template is IMHO a bit too far, and AFAIK it would be the first time in
>>>> the standard that such a thing would be made.
>>> The term "template function" would be more apt in this context, since a
>>> template function may refer either to an instantiation of a function
>>> template or function generated by the instantiation of a class template.
>>>
>>> The following active defect report addresses the inconsistent function
>>> template terminology in the current Standard:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2450.html#105
>>>
>> According to the resolution of DR105, the term "function template" has
>> been consistently removed from the standard wording in favor of the more
>> precise terms "template function" (1.3.11 and 13.3.1 and others) or
>> "member functions of class templates and member function templates"
>> (9.3).
>
> Are you sure you're trying to say what you just said? I see lots of
> instances of "function template" in the latest draft. "Function
> template" refers to something like this:
I apologize for the noise, I inverted by mistake "function template"
with "template function" in my statement above.
>
>> Why would you want to re-introduce the deprecated term?
>
> There's definitely no deprecation in DR 105.
>
Of course there's no formal deprecation of the term "template function",
but having it consistently removed from the standard looks definitely
like a (informal) deprecation of it.
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Greg Herlihy <greghe@mac.com>
Date: Thu, 8 Nov 2007 16:45:33 CST Raw View
On Nov 8, 12:09 pm, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> David Abrahams ha scritto:
>
>
>
> > on Tue Nov 06 2007, AlbertoBarbati-AT-libero.it (Alberto Ganesh Barbati) wrote:
>
> >> Greg Herlihy ha scritto:
> >>> On 11/5/07 11:24 AM, in article I3KXi.161547$%k.303...@twister2.libero.it,
> >>> "Alberto Ganesh Barbati" <AlbertoBarb...@libero.it> wrote:
>
> >>>> While I agree that the term "function template" might be stretched to
> >>>> also include member function templates, including members of a class
> >>>> template is IMHO a bit too far, and AFAIK it would be the first time in
> >>>> the standard that such a thing would be made.
> >>> The term "template function" would be more apt in this context, since a
> >>> template function may refer either to an instantiation of a function
> >>> template or function generated by the instantiation of a class template.
>
> >>> The following active defect report addresses the inconsistent function
> >>> template terminology in the current Standard:
>
> >>>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2450.html#105
>
> >> According to the resolution of DR105, the term "function template" has
> >> been consistently removed from the standard wording in favor of the more
> >> precise terms "template function" (1.3.11 and 13.3.1 and others) or
> >> "member functions of class templates and member function templates"
> >> (9.3).
>
> > Are you sure you're trying to say what you just said? I see lots of
> > instances of "function template" in the latest draft. "Function
> > template" refers to something like this:
>
> I apologize for the noise, I inverted by mistake "function template"
> with "template function" in my statement above.
>
>
>
> >> Why would you want to re-introduce the deprecated term?
>
> > There's definitely no deprecation in DR 105.
>
> Of course there's no formal deprecation of the term "template function",
> but having it consistently removed from the standard looks definitely
> like a (informal) deprecation of it.
"Function template" and "template function" have entirely different
meanings. Since each is an adjective-noun pairing, it should be clear
that a "function template" is a template (that generates functions) -
while "template function" is a function (generated from a template).
In the past, this distinction was not always maintained properly - and
"function template" would sometimes appear where "template function"
was intended.
Since the paragraph in question refers to all functions generated
directly - or indirectly - from a template, "template function" would
be the better choice than the "instantiated template specialization of
a constexpr function" (and would be much more succinct as well):
"If a constexpr template function would fail to satisfy the
requirements for a constexpr
function, the constexpr specifier is ignored and the template function
is
not a constexpr function."
Greg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: gdr@cs.tamu.edu (Gabriel Dos Reis)
Date: Fri, 9 Nov 2007 17:29:45 GMT Raw View
On Tue, 6 Nov 2007, Alberto Ganesh Barbati wrote:
| > | but a non-template member function of a class template may
| > | or may not be, depending on perspective.
| >
| > More to the point, how does that affect the constexpr specification?
| >
|
| I thought I had clearly expressed that in the OP, but apparently I
| wasn't. Let me recap with a code snippet:
|
| template <class T>
| class A
| {
| constexpr A(T x) : a(x)
| {}
|
| T a;
| };
|
| Clearly, A<int>::A() is a constexpr constructor. But what about, say,
| A<std::string>::A()?
|
| A<>::A() is a member of the class template A. It's *not* a function
| template so, with the current wording, paragraph [dcl.constexpr]/5 does
| not apply to it. That would make the specialization of A<std::string>::A
| ill-formed.
|
| However, I believe the intent is to ignore constexpr in that case and to
| allow A<std::string>::A. Could you please confirm that?
In earlier versions (pre Portland meeting) of the document, there was
no special case for (constexpr) entities that come from template
instantiations. The main reason was special cases almost always
attract troubles -- defeating regularity -- and one should be able to
travel between both world (template and non template) and essentially
get the same behaviour -- therefore only one rule suffices. People
should be able to read the template definition and have a reasonable
expectation about the instantiations without remembering special
rules. However, there was a discussion about special casing for implicitly
instantiated functions, then there was a mention that explicitly
instantiated template may also follow the same rule, hence the
suggested term 'instaniated template specialization'.
I don't feel bad about the above being ill-formed, but I won't stand
against allowing it either -- though I would prefer there is only a
single rule.
--
Dr. Gabriel Dos Reis (gdr@cs.tamu.edu), Assistant Professor
http://www.cs.tamu.edu/people/faculty/gdr
Texas A&M University -- Department of Computer Science
301, Bright Building -- College Station, TX 77843-3112
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: AlbertoBarbati@libero.it (Alberto Ganesh Barbati)
Date: Sun, 4 Nov 2007 15:32:26 GMT Raw View
Hi,
in the latest draft N2461, [dcl.constexpr]/5 reads:
"If the instantiated template specialization of a constexpr function
template would fail to satisfy the requirements for a constexpr
function, the constexpr specifier is ignored and the specialization is
not a constexpr function."
such wording implicitly excludes member functions of class templates and
member templates. However, the feature might be useful even in those
cases and there is no apparent reason why they should be excluded.
Proposed resolution:
Replace [dcl.constexpr]/5 with:
"If the instantiated template specialization of a constexpr function
template, member function of a class template or member template would
fail to satisfy the requirements listed in the previous paragraphs, the
constexpr specifier is ignored and the specialization is not a constexpr
function."
HTH,
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: gdr@cs.tamu.edu (Gabriel Dos Reis)
Date: Mon, 5 Nov 2007 17:14:39 GMT Raw View
On Sun, 4 Nov 2007, Alberto Ganesh Barbati wrote:
| Hi,
|
| in the latest draft N2461, [dcl.constexpr]/5 reads:
|
| "If the instantiated template specialization of a constexpr function
| template would fail to satisfy the requirements for a constexpr
| function, the constexpr specifier is ignored and the specialization is
| not a constexpr function."
|
| such wording implicitly excludes member functions of class templates and
| member templates. However, the feature might be useful even in those
| cases and there is no apparent reason why they should be excluded.
They are not excluded -- I see, however, how the sentence could be
read that way. `function template' in the above refers to all
kinds of function templates, including constructors, etc.
--
Dr. Gabriel Dos Reis (gdr@cs.tamu.edu), Assistant Professor
http://www.cs.tamu.edu/people/faculty/gdr
Texas A&M University -- Department of Computer Science
301, Bright Building -- College Station, TX 77843-3112
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: AlbertoBarbati@libero.it (Alberto Ganesh Barbati)
Date: Mon, 5 Nov 2007 19:24:14 GMT Raw View
Gabriel Dos Reis ha scritto:
> On Sun, 4 Nov 2007, Alberto Ganesh Barbati wrote:
>
> | Hi,
> |
> | in the latest draft N2461, [dcl.constexpr]/5 reads:
> |
> | "If the instantiated template specialization of a constexpr function
> | template would fail to satisfy the requirements for a constexpr
> | function, the constexpr specifier is ignored and the specialization is
> | not a constexpr function."
> |
> | such wording implicitly excludes member functions of class templates and
> | member templates. However, the feature might be useful even in those
> | cases and there is no apparent reason why they should be excluded.
>
> They are not excluded -- I see, however, how the sentence could be
> read that way. `function template' in the above refers to all
> kinds of function templates, including constructors, etc.
>
Such use of the term "function template" is not consistent with the use
established in clause 14 (see in particular 14.7/2, 14.7/3).
While I agree that the term "function template" might be stretched to
also include member function templates, including members of a class
template is IMHO a bit too far, and AFAIK it would be the first time in
the standard that such a thing would be made.
Just my opinion,
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: greghe@mac.com (Greg Herlihy)
Date: Tue, 6 Nov 2007 00:28:09 GMT Raw View
On 11/5/07 11:24 AM, in article I3KXi.161547$%k.303426@twister2.libero.it,
"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
> Gabriel Dos Reis ha scritto:
>> On Sun, 4 Nov 2007, Alberto Ganesh Barbati wrote:
>>
>> | in the latest draft N2461, [dcl.constexpr]/5 reads:
>> |
>> | "If the instantiated template specialization of a constexpr function
>> | template would fail to satisfy the requirements for a constexpr
>> | function, the constexpr specifier is ignored and the specialization is
>> | not a constexpr function."
>> |
>> | such wording implicitly excludes member functions of class templates and
>> | member templates. However, the feature might be useful even in those
>> | cases and there is no apparent reason why they should be excluded.
>>
>> They are not excluded -- I see, however, how the sentence could be
>> read that way. `function template' in the above refers to all
>> kinds of function templates, including constructors, etc.
>>
>
> Such use of the term "function template" is not consistent with the use
> established in clause 14 (see in particular 14.7/2, 14.7/3).
>
> While I agree that the term "function template" might be stretched to
> also include member function templates, including members of a class
> template is IMHO a bit too far, and AFAIK it would be the first time in
> the standard that such a thing would be made.
The term "template function" would be more apt in this context, since a
template function may refer either to an instantiation of a function
template or function generated by the instantiation of a class template.
The following active defect report addresses the inconsistent function
template terminology in the current Standard:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2450.html#105
Greg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: gdr@cs.tamu.edu (Gabriel Dos Reis)
Date: Tue, 6 Nov 2007 00:33:50 GMT Raw View
On Mon, 5 Nov 2007, Alberto Ganesh Barbati wrote:
| Such use of the term "function template" is not consistent with the use
| established in clause 14 (see in particular 14.7/2, 14.7/3).
however, it is coherent with 14.8 and other parts of the standard text.
|
| While I agree that the term "function template" might be stretched to
| also include member function templates, including members of a class
| template is IMHO a bit too far, and AFAIK it would be the first time in
| the standard that such a thing would be made.
|
| Just my opinion,
So, in your opinion, section 14.8 does not apply to member function
templates?
--
Dr. Gabriel Dos Reis (gdr@cs.tamu.edu), Assistant Professor
http://www.cs.tamu.edu/people/faculty/gdr
Texas A&M University -- Department of Computer Science
301, Bright Building -- College Station, TX 77843-3112
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: jdennett@acm.org (James Dennett)
Date: Tue, 6 Nov 2007 15:59:02 GMT Raw View
Gabriel Dos Reis wrote:
> On Mon, 5 Nov 2007, Alberto Ganesh Barbati wrote:
>
> | Such use of the term "function template" is not consistent with the use
> | established in clause 14 (see in particular 14.7/2, 14.7/3).
>
> however, it is coherent with 14.8 and other parts of the standard text.
>
> |
> | While I agree that the term "function template" might be stretched to
> | also include member function templates, including members of a class
> | template is IMHO a bit too far, and AFAIK it would be the first time in
> | the standard that such a thing would be made.
> |
> | Just my opinion,
>
> So, in your opinion, section 14.8 does not apply to member function
> templates?
A member function template is clearly a function template,
but a non-template member function of a class template may
or may not be, depending on perspective. There might be
room be to clearer here.
-- James
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: Gabriel Dos Reis <gdr@cs.tamu.edu>
Date: Tue, 6 Nov 2007 14:49:48 CST Raw View
On Tue, 6 Nov 2007, James Dennett wrote:
| Gabriel Dos Reis wrote:
| > On Mon, 5 Nov 2007, Alberto Ganesh Barbati wrote:
| >
| > | Such use of the term "function template" is not consistent with the use
| > | established in clause 14 (see in particular 14.7/2, 14.7/3).
| >
| > however, it is coherent with 14.8 and other parts of the standard text.
| >
| > |
| > | While I agree that the term "function template" might be stretched to
| > | also include member function templates, including members of a class
| > | template is IMHO a bit too far, and AFAIK it would be the first time in
| > | the standard that such a thing would be made.
| > |
| > | Just my opinion,
| >
| > So, in your opinion, section 14.8 does not apply to member function
| > templates?
|
| A member function template is clearly a function template,
thanks goodness,
| but a non-template member function of a class template may
| or may not be, depending on perspective.
More to the point, how does that affect the constexpr specification?
--
Dr. Gabriel Dos Reis (gdr@cs.tamu.edu), Assistant Professor
http://www.cs.tamu.edu/people/faculty/gdr
Texas A&M University -- Department of Computer Science
301, Bright Building -- College Station, TX 77843-3112
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: AlbertoBarbati@libero.it (Alberto Ganesh Barbati)
Date: Tue, 6 Nov 2007 21:41:39 GMT Raw View
Greg Herlihy ha scritto:
>
> On 11/5/07 11:24 AM, in article I3KXi.161547$%k.303426@twister2.libero.it,
> "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:
>
>>
>> While I agree that the term "function template" might be stretched to
>> also include member function templates, including members of a class
>> template is IMHO a bit too far, and AFAIK it would be the first time in
>> the standard that such a thing would be made.
>
> The term "template function" would be more apt in this context, since a
> template function may refer either to an instantiation of a function
> template or function generated by the instantiation of a class template.
>
> The following active defect report addresses the inconsistent function
> template terminology in the current Standard:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2450.html#105
>
According to the resolution of DR105, the term "function template" has
been consistently removed from the standard wording in favor of the more
precise terms "template function" (1.3.11 and 13.3.1 and others) or
"member functions of class templates and member function templates"
(9.3). Why would you want to re-introduce the deprecated term?
I believe my proposal goes precisely in the direction of the resolution
of DR105.
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]