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.

Sign up for GitHub

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

Jump to bottom

Inappropriate "Shall" in PostConditions: elements #4711

Closed
Dani-Hub opened this issue Jun 21, 2021 · 8 comments
Closed

Inappropriate "Shall" in PostConditions: elements #4711

Dani-Hub opened this issue Jun 21, 2021 · 8 comments

Comments

@Dani-Hub
Copy link
Member

During my recent survey of Postconditions: elements in the N4892 working draft I found two occurrences with inappropriate "shall" usage. A quick confirmation on the LWG reflector indicated that an editorial change would be appreciated:

  1. [util.smartptr.shared.const] p23:
shared_ptr(shared_ptr&& r) noexcept;
template<class Y> shared_ptr(shared_ptr<Y>&& r) noexcept;

[...]
23 Postconditions: *this shall contains the old value of r. r shall beis empty. and r.get() == nullptr.

  1. Table [tab:container.hash.req]:
Expression Return type pre-/post-condition
b.bucket(k) size_type [...]
Postconditions: The return value shall be
is in the range [0, b.bucket_count()).
@tkoeppe
Copy link
Contributor

tkoeppe commented Jun 21, 2021 •
edited

Great, thanks, could you send a pull request, or would you prefer if I just changed it directly?

@Dani-Hub Dani-Hub changed the title Inappropriate "Shall" in PostCondtions: elements Inappropriate "Shall" in PostConditions: elements Jun 21, 2021
@Dani-Hub
Copy link
Member Author

Would be great, if you could just change it directly, @tkoeppe - Thanks!

@tkoeppe
Copy link
Contributor

tkoeppe commented Jun 21, 2021 •
edited

Hm, we also say things like "get() == nullptr." a lot instead of "get() == nullptr is true." But that's pretty pervasive.

@Dani-Hub
Copy link
Member Author

Please feel free do make any further adjustments as appropriate, this was just my initial idea of a change suggestion.

@tkoeppe
Copy link
Contributor

tkoeppe commented Jun 21, 2021

Yes, I might open a new issue.

Original issue fixed by 6091e26 and a7ff942. Thanks!

@tkoeppe tkoeppe closed this as completed Jun 21, 2021
@jensmaurer
Copy link
Member

jensmaurer commented Jun 21, 2021 •
edited

Since I'm actively progressing the "dismantle requirements tables" pull request, this particular change just needlessly introduces conflicts at a rather inopportune time.

@Dani-Hub
Copy link
Member Author

So why no deferring it for a better occasion?

@tkoeppe
Copy link
Contributor

tkoeppe commented Jun 21, 2021

@jensmaurer: sorry about that! I hope this one small change can be back-ported to your pending PR, and I'll keep away from the tables henceforth!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Dani-Hub @tkoeppe @jensmaurer