-
Notifications
You must be signed in to change notification settings - Fork 772
[basic.life,basic.start.term,expr.delete] Clarify destruction of scalars #4953
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
base: main
Are you sure you want to change the base?
Conversation
Put onto core's inbox: https://wiki.edg.com/bin/view/Wg21telecons2021/CoreWorkingGroup |
So you're basically fine with https://lists.isocpp.org/core/2021/01/10409.php (meant to use |
I guess we need a special rule around "provides storage"; the examples there all suggest that if an object provides storage, using that storage to create another object does not end the lifetime of the object that provided the storage. |
Ah, we have that rule: [basic.life] p1.5 says the example is fine, because the outer array provides storage for the "int", and the lifetime of the outer array was not ended by creating the "int". |
But the lifetime of the array elements end. And they are destroyed when the array object is destroyed. |
So maybe as a special exception, the "provides storage" types (unsigned char, std::byte) shouldn't actually have lifetime-ending destruction. |
Can the form of the exception (either reusing their storage doesn't end their lifetime or destroying dead objects of few types is OK) be decided editorially? BTW, P1839 Accessing Object Representations says that the elements of an object representation are alive as long as the object is alive and that arrays of characters are «their own representations», so it looks like it keeps the elements of arrays providing storage alive when the new objects are created on top of them. Not sure if this was intended. |
There is nothing editorial here. Even the intention for the original example in #4944 is unclear. Note the "CWG" label liberally sprinkled about. |
Does the "CWG" label guarantees it is not editorial? I've thought there is "not-editorial" label for this and "CWG" means that CWG wants to take a look at this before fixing editorially. |
Don't worry, CWG will tell if it's not editorial. |
http://lists.isocpp.org/core/2021/01/10392.php
http://lists.isocpp.org/core/2021/09/11592.php
Fixes #4944