|
|
Boost-Commit : |
From: widman_at_[hidden]
Date: 2008-06-30 03:41:24
Author: james.widman
Date: 2008-06-30 03:41:23 EDT (Mon, 30 Jun 2008)
New Revision: 46887
URL: http://svn.boost.org/trac/boost/changeset/46887
Log:
Fixed several issues, ranging from nit-size to small-ish.
==================================
14.10 temp.constrained:
6 Within a constrained context, a program shall not refer to an
unconstrained template."
14.10.2 temp.archetype:
20 "[...]The template shall not be an unconstrained template."
--- This is not quite sufficient; we want to make sure that when a
template passes type deduction (e.g., for a function call, or
to see whether a class template partial specialization matches
a set of template arguments), it's not an unconstrained
template when we're in a constrained context.
In 14.8.2 temp.deduct, insert a new paragraph before p2:
"If the reference to the template occurs within a constrained
context and the template is an unconstrained template, type
deduction fails."
==================================
14.5.5 Class template partial specializations [temp.class.spec] p10:
"The template requirements of a primary class template are implied
(14.10.1.2) in its class template partial specializations."
--- append "...that are constrained templates."
==================================
14.8.2 temp.deduct p2, last bullet:
"If the specified template arguments do not satisfy the requirements
of the template (14.10.1), type deduction fails."
Two issues here:
--- Minor nit: the plural language is used instead of "any" or
"each".
--- Larger issue: This added bullet talks about the *specified*
arguments (i.e., args specified between angle brackets rather
than args deduced or which come from default args).
--- Another larger issue: The added bullet could be read as
something that needs to be checked just after *both* of the
two substitutions that can happen during overall type
deduction: The first substitution is done to substitute
parameters for which explicitly specified args were given.
The second happens after all other args have been deduced or
obtained from default args. The problem is that the first
substitution could leave you with only *partially* substituted
template arguments in the requirements, and satisfaction would
likely fail in that case. We need to make sure that we check
for whether a requirement is satisfied only *after* each of
its template arguments has been replaced with a concrete
thingy.
Suggested change: Delete the bullet and change p5 as indicated:
Modify:
"When all template arguments have been deduced or obtained from default
template arguments, all uses of template parameters in non-deduced
contexts are replaced with the corresponding deduced or default
argument values. If the substitution results in an invalid type, as
described above, type deduction fails."
...to:
"When ***each template argument*** has been ***explicitly
specified,*** deduced or obtained from default
template arguments, ***each use of a template parameter in the
function type and in each template requirement is***
replaced with the corresponding deduced or default
argument values. If the substitution results in an invalid type, as
described above, type deduction fails. ***If a substituted requirement
cannot be satisfied ([temp.req.sat]), type deduction fails.***"
==================================
3.4.3 basic.lookup.qual p6:
"In a constrained template (14.10), a name prefixed by a
nested-name-specifier that nominates a template type parameter T is
looked up (14.10.1.1) in the concept map archetype corresponding to
^^^^^^^^^^^ ^^^^^^^^^^^^^
each concept requirement (14.10.1) in the template requirements whose
template argument list contains T."
--- remove reference to 14.10.1.1.
--- Looking into the CMA would force its definition, which would
often force commitment of the archetypes associated with the
template parameters that are used as arguments in the
requirement. But in this context we really just need to know
that the user is referring to a particular member of a
concept. So 'T::type' (equivalent to 'C<T>::type') needs to
just look into the *concept* and find a type name. So we'll
remove 'map archetype' above and insert a note indicating that
a CMA definition is not required for this lookup. Also, the
new wording will indicate that we do req::I once for each
requirement; this implicitly calls into concept.qual.
We must also change 3.4.3.3 concept.qual accordingly (so that
'C<T>::type' does not cause CMA instantiation). if the thing
named is an associated type, just use that associated type
name. If it names an associated function, we need a CMA def.
Change p6 as indicated:
From:
In a constrained template (14.10), a name prefixed by a
nested-name-specifier that nominates a template type parameter T
is looked up (14.10.1.1) in each concept named by athe concept map
archetype corresponding to each concept requirement (14.10.1) in
the template requirements whose template argument list contains T.
That name shall refer to one or more associated types (names of
associated functions are ignored) that are all equivalent (14.4).
If qualified name lookup for associated types does not find any
associated type names, qualified name lookup (3.4.3) can still
find the name within the archetype (14.10.2) of T when the name
lookup is performed in a constrained context (14.10).
To:
"[...] that nominates a template type parameter T is looked up as follows:
for each template requirement C<args> whose template argument list
references T, the name is looked up as if the nested-name-specifier
referenced the concept instance of the requirement instead of T
(\mbox{\ref{concept.qual}}), except that only the names of associated
types are visible during this lookup. If an associated type of at
least one requirement is found, then each name found shall refer to
the same type. Otherwise (that is, if lookup yeilds an empty lookup
set for each requirement), the name is looked up within the scope of
the archetype associated with T, and each requirement member is
considered visible during this search."
Change concept.qual p1 as indicated:
From:
"If the nested-name-specifier of a qualified-id nominates a concept
map (not a concept), the name specified after the
nested-name-specifier is looked up in the scope of the concept map
(3.3.8) or any of the concept maps for concept instances its concept
instance refines (14.9.3.1). Concept map lookup (14.10.1.1) determines
which concept map the nested-name-specifier refers to. The name shall
represent one or more members of that concept map or the concept maps
corresponding to the concept refinements."
To:
"If the nested-name-specifier of a qualified-id nominates a concept
***instance***, the name specified after the nested-name-specifier is
looked up ***as follows:
- If the template argument list of the concept instance references
a template parameter or associated type of a concept or concept
map archetype, and if the name, when looked up within the scope
of the concept of the concept instance, unambiguously refers to
an associated type or class template, the result of
name lookup is the associated type or class template as a member
of the requirement. [Note: this implies that, given two distinct
type parameters T and U, C<T>::type and C<U>::type are distinct
types (though they may refer to the same archetype). --end note]
- Otherwise, concept map lookup ([temp.req.sat]) first determines
which concept map is referred to by the nested-name-specifier.
Then concept member lookup ([concept.member.lookup]) is used to
find the name within the scope of the concept map. The name
shall represent one or more members of that concept map or the
concept maps corresponding to the concept refinements."
==================================
14.9.2 concept.map p2:
"Whenever a constrained template specialization (14.10) is named,
there shall be a concept map that satisfies each concept requirement
in the template requirements (14.10.1.1)."
--- The "is named" language is a little weak. (Is it before or
after matching/overload resolution?) Replace with:
"For template argument deduction ([temp.deduct.type]) against
a constrained template to succeed, each requirement in the set of the
template's requirements shall be satisfied ([temp.req.sat])."
==================================
14.5.8 temp.concept.map p8:
"... result of an implicit or explicit instantiation..."
--- Change to: "... as the result of an instantiation ..."
==================================
[temp.inst] p15:
"[...] when name lookup finds a concept map member."
--- This is putting the cart before the horse; we need to
instantiate first, lookup second.
Change to:
"[...] when the nested-name-specifier of a qualified-id
references a concept instance ([concept.qual])."
Text files modified:
sandbox/committee/concepts/wording/wording.tex | 125 +++++++++++++++++++++++++++++++++------
1 files changed, 104 insertions(+), 21 deletions(-)
Modified: sandbox/committee/concepts/wording/wording.tex
==============================================================================
--- sandbox/committee/concepts/wording/wording.tex (original)
+++ sandbox/committee/concepts/wording/wording.tex 2008-06-30 03:41:23 EDT (Mon, 30 Jun 2008)
@@ -611,14 +611,30 @@
\addedConcepts{In a constrained template (\mbox{\ref{temp.constrained}}), a name prefixed by
a \mbox{\techterm{nested-name-specifier}} that nominates a template type
parameter \mbox{\tcode{T}} is looked up}
-\addedCC{(\mbox{\ref{temp.req.sat}})} \addedConcepts{in}
-\changedCC{each concept named by a}{the concept map
-archetype corresponding to each}
-\addedConcepts{concept requirement (\mbox{\ref{temp.req}}) in the template requirements
+\removedCCC{(\mbox{\ref{temp.req.sat}}) in
+the concept map archetype corresponding to each
+concept requirement (\mbox{\ref{temp.req}}) in the template requirements
whose template argument list contains \mbox{\tcode{T}}. That name
shall refer to one or more associated types (names of associated
functions are ignored) that are all equivalent (\mbox{\ref{temp.type}}).
-\mbox{\enterexample}}
+}
+\addedCC{as follows:
+for each template requirement
+ \mbox{\tcode{C<$args$>}}
+whose template argument list
+references T, the name is looked up as if the
+\mbox{\techterm{nested-name-specifier}} referenced
+\mbox{\tcode{C<$args$>}} instead of T (\mbox{\ref{concept.qual}}), except
+that only the names of associated types are visible during this lookup.
+If an associated type of at least one requirement is found, then each name
+found shall refer to the same type. Otherwise, if the reference to the
+name occurs within a constrained context, the name is looked up within the
+scope of the archetype associated with T (and no special restriction on
+name visibility is in effect for this lookup). \mbox{\enternote}\
+Otherwise, the name is a member of an unknown specialization
+\mbox{\ref{temp.dep.type}} \mbox{\exitnote}\
+}
+\addedConcepts{\mbox{\enterexample}}
\begin{codeblock}
concept C<typename T> {
typename assoc_type;
@@ -630,11 +646,11 @@
\end{codeblock}
\addedConcepts{\mbox{\exitexample}}
-\addedConcepts{If qualified name lookup for associated types does not
+\removedCCC{If qualified name lookup for associated types does not
find any associated type names, qualified name lookup
(\mbox{\ref{basic.lookup.qual}}) can still find the name within the
archetype (\mbox{\ref{temp.archetype}}) of \mbox{\tcode{T}}}
-\addedConcepts{when the name lookup is performed in a constrained context
+\removedCCC{when the name lookup is performed in a constrained context
(\mbox{\ref{temp.constrained}}).}
\color{black}
@@ -650,19 +666,53 @@
\mbox{\techterm{nested-name-specifier}}\
of a
\mbox{\techterm{qualified-id}}\
-nominates a concept map (not a concept),
+nominates a concept
+}\changedCC{map (not a concept)}{instance}\addedConcepts{,
the name specified after the
\mbox{\techterm{nested-name-specifier}}\
-is looked up in the scope of the concept map (\mbox{\ref{basic.scope.concept}}) or
-any of the concept maps for concept instances
+is looked up }
+\removedCCC{in the scope of the concept map
+(\mbox{\ref{basic.scope.concept}}) or any of the concept maps for concept
+instances
its concept instance refines
(\mbox{\ref{concept.member.lookup}}).}
-\addedConcepts{Concept map lookup (\mbox{\ref{temp.req.sat}}) determines
- which concept map the \mbox{\techterm{nested-name-specifier}} refers to.}
-\addedConcepts{The name shall represent one or
+\removedCCC{Concept map lookup (\mbox{\ref{temp.req.sat}}) determines
+ which concept map the \mbox{\techterm{nested-name-specifier}} refers
+ to.}
+\removedCCC{The name shall represent one or
more members of that
- concept map or the concept maps corresponding to the concept refinements.
- \mbox{\enternote} Outside of a constrained context, this means
+ concept map or the concept maps corresponding to the concept refinements.}
+\addedCC{ as follows:}
+\begin{itemize}
+\additemCC{
+If the template argument list of the concept instance references a
+template parameter or associated type of a requirement, and if the name,
+when looked up within the scope of the concept of the concept instance,
+unambiguously refers to an associated type or class template, the result
+of name lookup is the associated type or class template as a member of the
+requirement.
+ \mbox{\enternote}\ this implies that, given two distinct type parameters
+ T and U, C<T>::type and C<U>::type are distinct types (though they may
+ refer to the same archetype). Also, the mere lookup of 'type' within C<T>
+ and C<U> does not require the creation of a concept map archetype for
+ C<T> or C<U>.
+ \mbox{\exitnote}\ }
+\additemCC{
+Otherwise, concept map lookup (\mbox{\ref{temp.req.sat}}) first determines
+which concept map is referred to by the nested-name-specifier. Then
+concept member lookup (\mbox{\ref{concept.member.lookup}}) is used to find
+the name within the scope of the concept map. The name shall represent
+one or more members of that concept map or the concept maps corresponding
+to the concept refinements.
+ \mbox{\enternote}\
+ this lookup requires a concept map definition, so if the template
+ argument list of the concept instance references a template parameter
+ or associated type of a requirement, a concept map archetype
+ definition is required.
+ \mbox{\exitnote}\
+}
+\end{itemize}
+\addedConcepts{ \mbox{\enternote} Outside of a constrained context, this means
that one or more
requirement members (\mbox{\ref{concept.map}}) will be found, and since
those names are synonyms for sets of other names, the result of
@@ -2699,7 +2749,7 @@
\pnum \addedConcepts{The template requirements
of a primary class template are implied
(\mbox{\ref{temp.req.impl}}) in its class template partial
- specializations. \mbox{\enterexample} } \color{addclr}
+ specializations}\addedCC{ that are constrained templates}\addedConcepts{. \mbox{\enterexample} } \color{addclr}
\begin{codeblock}
concept LessThanComparable<typename T> { /* ... */ }
concept Hashable<typename T> { /* ... */ }
@@ -3107,7 +3157,9 @@
\pnum
\addedConcepts{A concept map template shall be declared before the first use of a
concept map that would make use of the concept map template
-as the result of an implicit or explicit instantiation
+as the result of an}
+\removedCCC{ implicit or explicit}
+\addedConcepts{ instantiation
in every translation unit in which such a use occurs; no diagnostic is
required.}
@@ -3265,7 +3317,10 @@
map is referenced in a context that requires the concept map
definition, either to satisfy a concept requirement
(\mbox{\ref{temp.req}})
-or when name lookup finds a concept map member.}
+or when }\changedCCC{name lookup finds a concept map member.}{the
+\mbox{\techterm{nested-name-specifier}} of a
+\mbox{\techterm{qualified-id}} references a concept instance
+(\mbox{\ref{concept.qual}}).}
\rSec2[temp.expl.spec]{Explicit specialization}
@@ -3295,6 +3350,13 @@
\rSec2[temp.deduct]{Template argument deduction}
\setcounter{Paras}{1}
\pnum
+\addedCC{
+If the reference to the template occurs within a constrained context
+(\mbox{\ref{temp.constrained}}) and the template is an unconstrained
+template, type deduction fails.
+}
+
+\pnum
When an explicit template argument list is specified, the template
arguments must be compatible with the template parameter list and must
result in a valid function type as described below; otherwise type
@@ -3460,11 +3522,29 @@
\end{itemize}
\item
-\addedConcepts{If the specified template arguments do not satisfy the
+\removedCCC{If the specified template arguments do not satisfy the
requirements of the template (\mbox{\ref{temp.req}}), type deduction
fails.}
\end{itemize}
+\setcounter{Paras}{5}
+\pnum
+When
+\changedCCC{
+ all template arguments have}{
+ each template argument has}
+ been \addedCC{explicitly specified,} deduced or obtained from default
+template arguments,
+\changedCCC{all uses of template parameters in non-deduced
+contexts are}{
+ each use of a template parameter in the
+ function type and in each template requirement is
+}replaced with the corresponding \removedCCC{deduced or default}
+argument value\removedCCC{s}. If the substitution results in an invalid
+type, as described above, type deduction fails.
+\addedCC{If a substituted requirement cannot be satisfied
+(\mbox{\ref{temp.req.sat}}), type deduction fails.}
+
\noindent\editorial{Add the following new sections to 14 [temp]:}
\setcounter{section}{8}
@@ -3973,10 +4053,13 @@
\pnum
\addedConcepts{Concept maps describe how a set of template arguments satisfy the
requirements stated in the body of a concept definition
-(\mbox{\ref{concept.def}}). Whenever a constrained template specialization
+(\mbox{\ref{concept.def}}). }
+\changedCCC{Whenever a constrained template specialization
(\mbox{\ref{temp.constrained}}) is named, there shall be a concept map that
satisfies each concept requirement in the
-template requirements (\mbox{\ref{temp.req.sat}}).}
+template requirements (\mbox{\ref{temp.req.sat}}).}{For template argument
+deduction (\mbox{\ref{temp.deduct.type}}) against a constrained template to succeed,
+each of the template's requirements shall be satisfied (\mbox{\ref{temp.req.set}}).}
%
\addedConcepts{The concept map is inserted into the scope in
which the concept map or concept map template (\mbox{\ref{temp.concept.map}})
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk