Changeset 46887
- Timestamp:
- Jun 30, 2008, 7:41:23 AM (14 years ago)
- Author:
- james.widman
- Message:
-
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])."
- (No files)
-
