Attribute based ABI opt-in

[SidneyCogdill]

P2785R4 adds new rules when reloc should not call relocate ctor to solve the ABI issue. However, this significantly complicates the design and hurts teachability, causing it to suffer from the same "std::move doesn't move" issue. Furthermore, the early destruction use-case is no longer reliably usable:

auto read_and_update() {
    std::lock_guard l{m_mtx};
    auto num = m_res.load();
    reloc l; // Early dropping the lock guard without requiring std::unique_lock.
    very_slow_update(num); // Assuming this a blocking call that takes a long time...
}

In the above case, if it's decided that reloc can be silently deferred to later stage, it can introduce a silent performance regression without the users knowing, which in turn causes the ecosystem to simply not trust the effectiveness of discard semantic, resulting in a mechanism that looks good on paper but gains none of real adoption.

I suggest that reloc mandates the operand to be an owned parameter, or is ill-formed (emits a compile time error). And use a new attribute to explicitly opt into the new ABI behavior:

void f2(std::unique_ptr<int> p);

auto f1(std::unique_ptr<int> [[owned]] p) {
    f2(reloc p);
}

Which forces p to be an owned parameter and callee-destroyed. This makes the ABI breakage strictly opt-in without hurting the explicitness of reloc operator.

[SebastienBini]

Hello, I think you are overstating the issue. P2785R4 states that:

• if the variable is not a function parameter, then the relocation is not silently discarded. Likewise, discarded reloc expressions are guaranteed to call the destructor
• if the variable is a function parameter passed by value, and its type provides a relocation constructor and no move constructor, then we have the same guarantees as above

In your example, l destructor is guaranteed to be called, hence releasing the lock reliably.

On discarded reloc expressions for value parameters:

• if the type provides a move constructor, then implementations are allowed to postpone the destruction of the object until the function exits (so to preserve the ABI). However, those expressions are not a no-op: in that case, a temporary object is move-constructed and destroyed. This will empty the source object of its resources and trigger the desired destructor effect.
• if the type provides a copy constructor and no relocation constructor, then such expressions are no-op and compilers are encouraged to emit a warning.

In other words you get:

• direct destructor call (relocation ctor and no move ctor)
• move-constructed temporary and destruction (move ctor)
• a warning which will likely be caught by Werror

Your suggestion with the [[owned]] attribute was already considered and was not favored. The main problem is that now [[owned]] is part of the function signature, and needs to be carried over to function pointers.
void (*f)(std::unique_ptr<int> [[owned]]) = f1;
It's a lot of boilerplate that will complicate the use of the feature and will be useless for some users as their build system already uses callee-destroy ABI.

[SidneyCogdill]

Thanks for your reply. My fault for not looking at the proposal closely enough. Indeed if the move constructor is called instead to mimic dropping the resource + no-op emits diagnostic message from compiler, then my issue with the predictability of discarded reloc behavior is very much mitigated, and the presence of move constructor is common enough in C++ ecosystem to not cause usability issue.

As of the repetitiveness of the ABI attribute, it doesn't have to be in function parameter. For example, it should be possible to annotate them namespace-wide to state that everything under this namespace in this translation unit should opt into the new ABI (and will automatically slap [[owned]] to the function parameters under the hood). And because the namespace itself is visible within the header, the caller side should have full visibility into the ABI attribute and use the new ABI behavior accordingly without requiring explicit annotation on function pointers.

Of course if the header and source have unmatched ABI attribute for the namespace then it's (very likely) ILNDR, but that's kind of expected and there's already a mitigation for that today, which is to #include the header within the corresponding source file so that the compiler can look into the declaration for signature dismatch.

But I agree that the currently proposed behaviors in R4 is good enough to not bother with (the hassles of) ABI attributes. You can close this issue if you want (or you can keep it open if you do want function/class/namespace-wide ABI attribute).