On Wednesday, 23 August 2023 20:26:13 PDT Arthur O'Dwyer wrote:
> On Wed, Aug 23, 2023 at 5:31 PM Thiago Macieira via Std-Proposals <
>
> std-proposals_at_[hidden]> wrote:
> > How about instead we add a constructor to std::mutex to allow it to be
> > born locked?
>
> Well, because the issue here isn't *really* about making a mutex that's
> locked. That's just a very convenient *concrete example *of the general
> problem. If we gave std::mutex a constructor that allowed it to be born
> locked, then we'd have to invent a *new* concrete example to demonstrate
> the general problem. (Like maybe "making a vector with a given capacity.")

I disagree. I remain skeptical that there is a general problem in the first
place. I'd like to hear more examples that would show it is a general problem
that needs solving, but that hasn't happened yet. And do note that "std::mutex
and widgets" aren't two instances of a general problem, they are the same
problem twice under a different name.

I also call returning std::mutex a minor corner-case. I don't think it even
makes sense semantically. The objective is not to return a new std::mutex or
widget, but to configure options on one. Even if the problem is the ability to
call a given constructor, we already have three different ways to do this:
std::optional, std::shared_ptr and raw pointer.

And if the problem isn't the constructor, but setting options, then we
definitely don't need to return said object and there's no additional cost in
passing the pre-constructed object by reference.

Finally, see my other reply about whether this risky and whether more
conservative solutions should be sought instead, especially if we determine
that only very minor corner-cases would be addressed by this and only because
we don't want to use any of the other alternatives.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering