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

[basic.life]/6 and [basic.life]/7 Duplicate wording regarding access outside of lifetime #5763

Open
blackteahamburger opened this issue Aug 21, 2022 · 5 comments
Open

[basic.life]/6 and [basic.life]/7 Duplicate wording regarding access outside of lifetime #5763

blackteahamburger opened this issue Aug 21, 2022 · 5 comments

Comments

@blackteahamburger
Copy link
Contributor

blackteahamburger commented Aug 21, 2022 •
edited

The wording for [basic.life]/6 and [basic.life]/7 is basically the same, except:

  • [basic.life]/6.2: the pointer is used to access a non-static data member or call a non-static member function of the object

is not the same as

  • [basic.life]/7.1: the glvalue is used to access the object
  • [basic.life]/7.2: the glvalue is used to call a non-static member function of the object

[basic.life]/6 lacks a description of using pointers to access the object, but the lvalue result of pointer dereferencing still applies to [basic.life]/7.1. [basic.life]/7 lacks a description of accessing a non-static data member of the object, but accessing a non-static data member of the object is accessing the object.

And wording that applies only to pointers in [basic.life]/6:

  • [basic.life]/6.1: the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression
  • [basic.life]/6.4: the pointer is used as the operand of a static_­cast ([expr.static.cast]), except when the conversion is to pointer to cv void, or to pointer to cv void and subsequently to pointer to cv char, cv unsigned char, or cv std​::​byte ([cstddef.syn])

This creates unnecessary repetition and can be confusing. So, wording similar to cppreference#Access outside of lifetime can be used.
@frederick-vs-ja
Copy link
Contributor

I think this deserves a CWG issue.

And [basic.life]/(6.4) is problematic to me: it seemly prohibits std::construct_at(static_cast<T*>(p), args...) to be a "more elegant" alternative for ::new (p) T(args...).

@blackteahamburger
Copy link
Contributor Author

blackteahamburger commented Aug 23, 2022 •
edited

Why is this issue not editorial?

There are more than one issues with this paragraph, see also https://stackoverflow.com/q/73434558.

However, I think it should be a issue with std::construct_at, it should be changed to:

template<class T, class... Args>
constexpr T* construct_at( void* p, Args&&... args );

T must be explicitly provided:

std::construct_at<T>(p, args...)

@jensmaurer
Copy link
Member

As you have shown, there is deviating wording between p6 and p7, and it's not at all obvious whether that is intended to be the same or not. Plus, a wording change of that scale is best reviewed by CWG instead of doing that editorially.

@jensmaurer
Copy link
Member

CWG1530 is mildly related.

@jensmaurer
Copy link
Member

I'm seeing how p6.2 is redundant with p7.1 and p7.2 (because a pointer gets dereferenced to an lvalue in [expr.ref]).

It is unclear what "access the object" means; see CWG1530.

Once we remove p6.2, the repetition is cut down; the reference and pointer dynamic_cast cases are actually different cases and I'm not sure we can somehow avoid the redundancy here.

Would the removal of p6.2 be sufficiently helpful here to warrant a separate core issue; leaving the larger topic of CWG1530 for another time?

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
@frederick-vs-ja @jensmaurer @blackteahamburger