On 18 May 2024 19:03:29 BST, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Saturday, May 18, 2024, Arthur O'Dwyer wrote:
>
>>
>> Your "Proposed Wording" is only one sentence. It refers to something
>> called "std::elide," which is never defined in the wording.
>>
>> Your section 1 claims that it's *not* possible to emplace a
>> `counting_semaphore` into an `optional`, but in fact section 2.1 shows that
>> it *is* possible.
>>
>> The thing that's *actually* impossible in today's C++ is to return a
>> *mutated* immovable object, as in:
>> std::mutex ReturnLockedMutex() {
>> std::mutex m;
>> m.lock();
>> return m;
>> }
>> and your `std::elide` idea doesn't help with that.
>>
>
>
>Depends on our definition of 'possible'. Does 'possible' mean that it's
>doable and easily doable, or does 'possible' mean that it's in some way
>possible even if you need to do something clever and make a bit of an
>effort? 9 out of 10 programmers don't know about the conversion operator
>trick. And as you mentioned in your blog, the conversion operator trick
>doesn't work with templated constructors, hence the need for a core
>language change.
>
>And as for your locked mutex:
>
>void LockedMutex(void *const p)
>{
> auto &m = *::new(p) mutex;
> m.lock();
>}
>
>auto ReturnLockedMutex = (mutex(*)(void))&LockedMutex;
>
>This will work on every platform except for the four mentioned in this
>paper: http://www.virjacode.com/papers/paper_nrvo_latest.pdf
>
>But does this fall under the umbrella of 'possible'? A theoretical
>programmer would say it's undefined behaviour, but an actual 9-to-5
>programmer would tell you it's tested and working on 27 compilers.

This is "possible" in the sense that it's UB, and the UB manifests (possibly) in a function that returns a locked mutex.

I know what you are getting at, but it's currently inexpressible in portable standard C++.