[basic.life] Unclear distinction between `reused` and `released` (for storage)

[safocl]

Full name of submitter (unless configured in github; will be published with the issue): Safocl Stollmannovic

Reference (section label): p2.5

The lifetime of an object o of type T ends when:
(2.5) the storage which the object occupies is released, or is reused by an object that is not nested within o ([intro.object]).

Link to reflector thread (if any): #884 (comment) (and below), #885

Issue description:
It's not clear in which cases storage is reused and when it's released. In my opinion, it's perfectly clear when storage is deallocated (release) (the scope in which the storage was created has ended) and when another object is created within the storage in a portion of bytes previously occupied by an object (reuse).
However, this distinction isn't clear when the lifetime of the byte array that provides the storage for an object expires.
1.

alignas(int) unsigned char buffer[8];

int main() {
    auto ptr_int = new (buffer) int{};
    auto ptr_char = new (buffer) char{}; // #1 storage for `int` was reused
    auto storage_ptr = new (&buffer) unsigned char[8]; // #2 storage for `char` was released?
}

#include <print>

struct alignas(int) S{
    unsigned char s[sizeof(int)];
    S(){std::println("S()");}
    ~S(){std::println("~S()");}
};

int main(){
    S s{}; // #1
    auto int_ptr = new(s.s) int{42}; // #2
    std::println("int = {}", *int_ptr); // #3
    s.~S(); // #4
    // std::println("int = {}", *int_ptr); // #5
    new(&s) S{};
}

What's going on in line #4? Is this where the storage release occurs? In line #5, we can't correctly access the data through the int_ptr pointer (for what reason)?

It's also unclear from this: if the lifetime of a byte array ends, then the objects nested within it that aren't elements of the array also end their lifetimes? (If such an action triggers a storage release, then the lifetime of such nested objects ends accordingly, as I expect.)

[intro.object#4]

4 An object a is nested within another object b if
(4.1) a is a subobject of b, or
(4.2) b provides storage for a, or
(4.3) there exists an object c where a is nested within c, and c is nested within b.

Suggested resolution:
Perhaps we should explicitly describe when storage is reused and when it is released? (Or introduce appropriate descriptions for "storage release" and "storage reuse")

[languagelawyer]

AFAIK, for a long time they have wanted the rule that an object's lifetime ends when the lifetime of its containing object ends. This makes your #5 illegal. And this is not (directly) related to storage reuse/release

[frederick-vs-ja]

Reusing with a new-expression is somehow defined now, see #278 and CWG2721. But it's still unclear whether implicit object creation also reuses storage. IMO it should.

Releasing of storage should be inferred from "the storage [...] lasts [...]" in [basic.stc] and calls to deallocation functions (and free etc.).

[safocl]

Reusing with a new-expression is somehow defined now, see #278 and CWG2721.

but it's precisely about the impossibility of validly using subobjects of an object in whose place a new object is created for its initialization, and not about the certainty of reuse

[safocl]

But it's still unclear whether implicit object creation also reuses storage. IMO it should.

But this is precisely the essence of what I find unclear: you can't create implicit objects without performing operations that do so. One such operation is creating a byte array (std::byte, unsigned char). But in this case, as I believe, the standard formally "hints" at a storage release in which objects that are not elements of this array were created. As I understand it, there is currently no consensus on how these definitions should be understood. But in my case, everything immediately falls into place and doesn't require any other rules. It only requires explicitly defining that these actions constitute a release.

[safocl]

Releasing of storage should be inferred from "the storage [...] lasts [...]" in [basic.stc] and calls to deallocation functions (and free etc.).

But what I'm talking about is that it's unclear whether the lifetime of nested objects that aren't array elements ends when the lifetime of the byte array that provides them storage ends. After all, the nested objects in my example, according to [basic.stc#general-2], have a "dynamic storage duration" although the object that provides them storage may have a different, independent "storage duration".

[frederick-vs-ja]

Releasing of storage should be inferred from "the storage [...] lasts [...]" in [basic.stc] and calls to deallocation functions (and free etc.).

But what I'm talking about is that it's unclear whether the lifetime of nested objects that aren't array elements ends when the lifetime of the byte array that provides them storage ends. After all, the nested objects in my example, according to [basic.stc#general-2], have a "dynamic storage duration" although the object that provides them storage may have a different, independent "storage duration".

I'd say this case shouldn't be about releasing storage. It's weird to say the same region of storage can be released multiple times. Note that you can destroy s, transparently replace s, and then re-create an int object within s.s many times.

If we want to clarify that the lifetime of the object created at #2 ends when the enclosing s is destroyed, IMO we should just add a new case to [basic.life]/2.

[safocl]

It's weird to say the same region of storage can be released multiple times.

More no than yes, in my understanding. This is the basis of the confusion. For s, storage has automatic duration. However, for nested objects in s.s, storage duration is based on the lifetime of s.s itself (including the lifetime of s) (in my understanding, since s.s provides storage for nested objects). In this case, no multiple storage releases occur. Under this interpretation, storage for nested objects is also released once (at the end of the s.s lifetime).

Note that you can destroy s, transparently replace s, and then re-create an int object within s.s many times.

Yes, but does this contradict the generally accepted interpretation of the standard? After all, we can already recreate nested objects (reuse storage) multiple times.

If we want to clarify that the lifetime of the object created at #2 ends when the enclosing s is destroyed, IMO we should just add a new case to [basic.life]/2.

Yes, this option is also possible, but in my case this omission is immediately eliminated, as well as the omission regarding the clear definition of "reuse" and "release".

[frederick-vs-ja]

In this case, no multiple storage releases occur.

I meant that "storage releases" (in your interpretation) may occur when repeatedly "destroy s, transparently replace s, and then re-create an int object within s.s".

IMO, In such operation sequence, the storage for the nested int object is always the certain sizeof(int) bytes, located at the beginning of the storage for s. I think it's weird to say this region of storage can be released multiple times.

[safocl]

IMO, In such operation sequence, the storage for the nested int object is always the certain sizeof(int) bytes, located at the beginning of the storage for s. I think it's weird to say this region of storage can be released multiple times.

What if this is wrapped in custom new and delete operators?