Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[unique.ptr] Remove definition of 'transfers ownership'. #1812

Merged
merged 1 commit into from Apr 1, 2018

Conversation

jensmaurer
Copy link
Member

@jensmaurer jensmaurer commented Nov 15, 2017

It is mostly subsumed by the detailed descriptions of the move
constructors and assignment operators.

Fixes #1643.

@zygoloid
Copy link
Member

I would like us to consider an alternative: retain the definition of transfer of ownership, and replace the repeated postconditions with

\postcondition As specified for transfer of ownership from \tcode{foo} to \tcode{bar}\iref{unique.ptr}.

I'm weakly in favor of this alternative, to reduce duplication and give us somewhere central to talk about unique_ptr's ownership semantics. However, if there's some reason the duplicated-postconditions approach is superior, I expect it would not take much to change my mind.

@jensmaurer
Copy link
Member Author

jensmaurer commented Nov 27, 2017

So, we would substantially shorten the existing postconditions.

Hm.. The "transfer ownership" wording is imprecise regarding the deleter: It says "if the pre-transfer u.d maintained state, such state has been transferred to u2.d", but the move constructors actually say that we copy-constructor or move-construct the deleter. Oh, move-assignment actually shows code rather than weasely prose.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Feb 12, 2018
\effects Constructs a \tcode{unique_ptr} by transferring ownership from
\tcode{u} to \tcode{*this}. If \tcode{D} is a reference type, this
\effects Constructs a \tcode{unique_ptr} from
\tcode{u}. If \tcode{D} is a reference type, this
deleter is copy constructed from \tcode{u}'s deleter; otherwise, this
deleter is move constructed from \tcode{u}'s deleter. \begin{note} The
deleter constructor can be implemented with \tcode{std::forward<D>}. \end{note}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Drive-by:) "The construction of the deleter" would be more correct here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jensmaurer: ping

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@zygoloid
Copy link
Member

OK. The idea of using "transfers ownership" to mean the relevant set of rules doesn't work out, because the rules are different each time (we transfer the deleter in different ways, and may or may not reset the destination first). Let's go with this patch or something like it.

It is mostly subsumed by the detailed descriptions of the move
constructors and assignment operators.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants