C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::elide

From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Date: Sat, 18 May 2024 19:03:29 +0100
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.

Received on 2024-05-18 18:03:32