From 283b722356801056e5e95891e9ed09a12526f611 Mon Sep 17 00:00:00 2001 From: Casey Carter Date: Thu, 9 Mar 2017 18:21:45 -0800 Subject: [PATCH] [P0547] Reorganize bullets in Move/CopyConstructible per LWG Kona direction --- ext/constructible/P0547.html | 22 ++++++++-------------- ext/constructible/constructible.md | 18 +++++++----------- 2 files changed, 15 insertions(+), 25 deletions(-) diff --git a/ext/constructible/P0547.html b/ext/constructible/P0547.html index 7443a976..0eb89819 100644 --- a/ext/constructible/P0547.html +++ b/ext/constructible/P0547.html @@ -232,7 +232,7 @@

4 Propos

The issue was discussed in the Issaquah 2016 meeting. The guidance given there was to narrowly focus this concept on “traditional” assignability only – assignments to non-const lvalues from non-proxy expressions – and solve the proxy problem at a later date. That is the direction taken here.]

[Editor’s note: Move subsection “Concept Destructible” ([concepts.lib.object.destructible]) to subsection “Core language concepts” ([concepts.lib.corelang]) after [concepts.lib.corelang.swappable], change its stable id to [concepts.lib.corelang.destructible] and edit it as follows:]

-

1 The Destructible concept is the base of the hierarchy of object concepts. It specifies properties that all such object types have in common.The Destructible concept specifies properties of all types instances of which can be destroyed at the end of their lifetime, or reference types.

+

1 The Destructible concept is the base of the hierarchy of object concepts. It specifies properties that all such object types have in common.The Destructible concept specifies properties of all types, instances of which can be destroyed at the end of their lifetime, or reference types.

template <class T>
concept bool Destructible() {
@@ -311,14 +311,11 @@

4 Propos     ConvertibleTo<remove_cv_t<T>&&, T>();
}

-

1 If T is an object type, then

+

1 If T is an object type, then let rv be an rvalue of type remove_cv_t<T> and u2 a distinct object of type T equal to rv. Then MoveConstructible<T>() is satisfied if and only if

-

​(1.1) Let rv be an rvalue of type remove_cv_t<T> and u2 a distinct object of type T equal to rv. Then MoveConstructible<T>() is satisfied if and only if

-
-

(1.1.1) – After the definition T u = rv;, u is equal to u2the value of rv before the construction.

-

(1.1.2) – T{rv} or *new T{rv} is equal to u2the value of rv before the construction.

-
-

​(1.2) If T is not const, rv’s resulting state is unspecified; otherwise, it is unchanged. [ Note: rv must still meet the requirements of the library component that is using it. The operations listed in those requirements must work as specified whether rv has been moved from or not. –end note ]

+

(1.1) – After the definition T u = rv;, u is equal to u2the value of rv before the construction.

+

(1.2) – T{rv} or *new T{rv} is equal to u2the value of rv before the construction.

+

​(1.32) If T is not const, rv’s resulting state is valid but unspecified ([lib.types.movedfrom]); otherwise, it is unchanged.

[Editor’s note: We no longer strip top-level const from the parameter to harmonize MoveConstructible with is_move_constructible. And as with is_move_constructible, MoveConstructible<int&&>() is true. See LWG#2146.

@@ -338,13 +335,10 @@

4 Propos     Constructible<T, const T&&>() && ConvertibleTo<const T&&, T>();
}

-

1 If T is an object type, then

+

1 If T is an object type, then let v be an lvalue of type (possibly const) remove_cv_t<T> or an rvalue of type const remove_cv_t<T>. Then CopyConstructible<T>() is satisfied if and only if

-

​(1.1) Let v be an lvalue of type (possibly const) remove_cv_t<T> or an rvalue of type const remove_cv_t<T>. Then CopyConstructible<T>() is satisfied if and only if

-
-

(1.1.1) – After the definition T u = v;, v is equal to u.

-

(1.1.2) – T{v} or *new T{v} is equal to v.

-
+

(1.1) – After the definition T u = v;, u is equal to v.

+

(1.2) – T{v} or *new T{v} is equal to v.

[Editor’s note: As with MoveConstructible, we no longer strip top-level cv-qualifiers to bring CopyConstructible into harmony with is_copy_constructible.

diff --git a/ext/constructible/constructible.md b/ext/constructible/constructible.md index c9791377..b4c7674d 100644 --- a/ext/constructible/constructible.md +++ b/ext/constructible/constructible.md @@ -229,15 +229,13 @@ In the "Proposed Resolution" that follows, there are editorial notes that highli > >     ConvertibleTo<remove_cv_t<T>&&, T>(); > > } > -> 1 If `T` is an object type, then +> 1 If `T` is an object type, then let `rv` be an rvalue of type `remove_cv_t<``T``>` and `u2` a distinct object of type `T` equal to `rv`. Then `MoveConstructible()` is satisfied if and only if > -> > ​(1.1) Let `rv` be an rvalue of type `remove_cv_t<``T``>` and `u2` a distinct object of type `T` equal to `rv`. Then `MoveConstructible()` is satisfied if and only if +> > (1.1) -- After the definition `T u = rv;`, `u` is equal to `u2`the value of `rv` before the construction. > > -> > > (1.1.1) -- After the definition `T u = rv;`, `u` is equal to `u2`the value of `rv` before the construction. -> > > -> > > (1.1.2) -- `T{rv}` or `*new T{rv}` is equal to `u2`the value of `rv` before the construction. +> > (1.2) -- `T{rv}` or `*new T{rv}` is equal to `u2`the value of `rv` before the construction. > > -> > ​(1.2) If `T` is not `const`, `rv`'s resulting state is unspecified; otherwise, it is unchanged. [ _Note:_ `rv` must still meet the requirements of the library component that is using it. The operations listed in those requirements must work as specified whether `rv` has been moved from or not. --_end note_ ] +> > ​(1.32) If `T` is not `const`, `rv`'s resulting state is valid but unspecified ([lib.types.movedfrom]); otherwise, it is unchanged. [_Editor's note:_ We no longer strip top-level `const` from the parameter to harmonize `MoveConstructible` with `is_move_constructible`. And as with `is_move_constructible`, `MoveConstructible()` is `true`. See [LWG#2146](https://cplusplus.github.io/LWG/lwg-active.html#2146). @@ -257,13 +255,11 @@ In the "Proposed Resolution" that follows, there are editorial notes that highli > >     Constructible<T, const T&&>() && ConvertibleTo<const T&&, T>(); > > } > -> 1 If `T` is an object type, then +> 1 If `T` is an object type, then let `v` be an lvalue of type (possibly `const`) `remove_cv_t<``T``>` or an rvalue of type `const` `remove_cv_t<``T``>`. Then `CopyConstructible()` is satisfied if and only if > -> > ​(1.1) Let `v` be an lvalue of type (possibly `const`) `remove_cv_t<``T``>` or an rvalue of type `const` `remove_cv_t<``T``>`. Then `CopyConstructible()` is satisfied if and only if +> > (1.1) -- After the definition `T u = v;`, `u` is equal to `v`. > > -> > > (1.1.1) -- After the definition `T u = v;`, `v` is equal to `u`. -> > > -> > > (1.1.2) -- `T{v}` or `*new T{v}` is equal to `v`. +> > (1.2) -- `T{v}` or `*new T{v}` is equal to `v`. [_Editor's note:_ As with `MoveConstructible`, we no longer strip top-level _cv_-qualifiers to bring `CopyConstructible` into harmony with `is_copy_constructible`.