tmp/tmpzwo6c2t0/{from.md → to.md}
RENAMED
|
@@ -6,30 +6,31 @@ while enforcing semantic requirements on that interaction.
|
|
| 6 |
|
| 7 |
The type of a customization point object, ignoring cv-qualifiers, shall
|
| 8 |
model `semiregular` [[concepts.object]].
|
| 9 |
|
| 10 |
All instances of a specific customization point object type shall be
|
| 11 |
-
equal [[concepts.equality]].
|
|
|
|
|
|
|
| 12 |
|
| 13 |
-
The type `T` of a customization point object
|
| 14 |
-
`invocable<
|
| 15 |
-
`Args...`
|
| 16 |
-
|
| 17 |
-
customization point object’s
|
| 18 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 19 |
|
| 20 |
Each customization point object type constrains its return type to model
|
| 21 |
a particular concept.
|
| 22 |
|
| 23 |
-
[*Note 1*: Many of the customization point objects in the library
|
| 24 |
-
evaluate function call expressions with an unqualified name which
|
| 25 |
-
results in a call to a program-defined function found by argument
|
| 26 |
-
dependent name lookup [[basic.lookup.argdep]]. To preclude such an
|
| 27 |
-
expression resulting in a call to unconstrained functions with the same
|
| 28 |
-
name in namespace `std`, customization point objects specify that lookup
|
| 29 |
-
for these expressions is performed in a context that includes deleted
|
| 30 |
-
overloads matching the signatures of overloads defined in namespace
|
| 31 |
-
`std`. When the deleted overloads are viable, program-defined overloads
|
| 32 |
-
need be more specialized [[temp.func.order]] or more constrained
|
| 33 |
-
[[temp.constr.order]] to be used by a customization point
|
| 34 |
-
object. — *end note*]
|
| 35 |
-
|
|
|
|
| 6 |
|
| 7 |
The type of a customization point object, ignoring cv-qualifiers, shall
|
| 8 |
model `semiregular` [[concepts.object]].
|
| 9 |
|
| 10 |
All instances of a specific customization point object type shall be
|
| 11 |
+
equal [[concepts.equality]]. The effects of invoking different instances
|
| 12 |
+
of a specific customization point object type on the same arguments are
|
| 13 |
+
equivalent.
|
| 14 |
|
| 15 |
+
The type `T` of a customization point object, ignoring *cv-qualifier*s,
|
| 16 |
+
shall model `invocable<T&, Args...>`, `invocable<const T&, Args...>`,
|
| 17 |
+
`invocable<T, Args...>`, and `invocable<const T, Args...>`
|
| 18 |
+
[[concept.invocable]] when the types in `Args...` meet the requirements
|
| 19 |
+
specified in that customization point object’s definition. When the
|
| 20 |
+
types of `Args...` do not meet the customization point object’s
|
| 21 |
+
requirements, `T` shall not have a function call operator that
|
| 22 |
+
participates in overload resolution.
|
| 23 |
+
|
| 24 |
+
For a given customization point object `o`, let `p` be a variable
|
| 25 |
+
initialized as if by `auto p = o;`. Then for any sequence of arguments
|
| 26 |
+
`args...`, the following expressions have effects equivalent to
|
| 27 |
+
`o(args...)`:
|
| 28 |
+
|
| 29 |
+
- `p(args...)`
|
| 30 |
+
- `as_const(p)(args...)`
|
| 31 |
+
- `std::move(p)(args...)`
|
| 32 |
+
- `std::move(as_const(p))(args...)`
|
| 33 |
|
| 34 |
Each customization point object type constrains its return type to model
|
| 35 |
a particular concept.
|
| 36 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|