> But as I have explained there cannot be a
“getMutexTheOtherTeamToldMeToUse()” because it is a std::mutex and it must
be initialized at the address provided by the caller.

Exactly! It doesn't work because the language doesn't allow it to work. If
the language allowed it to work, then it would work!
By your reasoning, this should also not work:

std::mutex getMutex() { return std::mutex(); }

But it does, because the language mandates to not copy and not move. The
language mandates that (using your words) *it must be initialized at the
address provided by the caller*.
Now, it would be beautiful if we could do:

std::mutex my_company::factory::getMutex() {
    return_and_execute std::mutex(), [] (auto& m) {
         logger.log("Created a mutex at %p", &m)
    }
}

That would allow me to do what the language already allows for, but also
give me the opportunity to execute code on top of that returned object.
Another option would be to mandate NRVO, then we could write:

std::mutex my_company::factory::getMutex() {
    [[nrvo]] std::mutex m;
    logger.log("Created a mutex at %p", &m);
    return m;
}

There are ways you can inject behavior after the object construction (like
creating a derived class) so there is no fundamental limitation.

Best Regards,
Breno G.





On Wed, May 22, 2024 at 12:00 PM Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> As mentioned before, it is not enough to have a theoretical discussion,
> you need a practical reason to justify adding a new feature.
> You have to consider alternative ways to do what you are trying to do, and
> then justify why your approach is better.
> And what has been displayed was a convoluted amount of code to try and
> write something that shouldn't been written, and whose alternative is a
> single line of code.
>
> The argument is not convincing, and you need to convince me that other
> objects that are also not movable don't have the exact same issues,
> justifying why you need to enforce RVO instead of passing in a reference.
> Get an example that actually needs it, then we have a point of discussion,
> until then it is not solving a problem.
> I hope I made my point clear.
>
>
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of
> Frederick Virchanza Gotham via Std-Proposals
> Sent: Wednesday, May 22, 2024 16:37
> To: std-proposals_at_[hidden]
> Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
> Subject: Re: [std-proposals] std::elide
>
> On Wed, May 22, 2024 at 2:17 PM Tiago Freire wrote:
> >
> > While I can understand RVO, mutexes has got to be the worst possible
> > example for an application of this.
>
>
> Let's say it's Summer time and I'm out the back garden at my house on a
> sunny day, and I'm trying out my brand new fruit blender. Tiago, you come
> over to my house and I've already made my smoothie, but there's still one
> pineapple sitting on the table, and even though a pineapple isn't a great
> choice of fruit for blending, it's right there right now and so I just grab
> it and throw it in the blender to show off my new blending skills. I could
> have stood up and walked into my house to the kitchen to grab a softer
> piece of fruit but I'm just not bothered -- the pineapple is there and it
> will do.
>
> We've been consistently using "std::mutex" because it's right there right
> now. We just need to write "#include<mutex>" and we have an
> unmovable-and-uncopyable type. That's literally the only reason we're all
> talking about mutexes in this thread. It's easier to write those
> 15 characters, "#include<mutex>", than to go to the bother of typing
> out:
>
> struct S {
> MyClass(MyClass const &) = delete;
> MyClass(MyClass &&) = delete;
> int n;
> };
>
> You seem to be very technically-minded Tiago and perhaps that's why you
> drill further into the logic than the rest of us here. Sometimes though, we
> just want a quick-and-easy example to demonstrate an idea we're working on
> -- and sometimes we don't give much consideration to how sensible our
> quick-and-easy example is. The world would probably be a better place if we
> were all as analytically-prone as you Tiago, but for the time being we just
> want to write out short little simple code snippets.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>