Tiago,

Please display some patience with people, and assume good faith.

People who take the time to write to this list might not have done enough
work to warrant committee time, but are usually the influencers within
their organisations because of their enthusiasm.

C++ is a large language - helping people here will spread your teaching
wide.

Let's cultivate a nurturing community.

On Mon, Mar 25, 2024, 03:58 Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> This makes absolutely no sense whatsoever.
> The lock_guard cannot own the object that represents the lock.
> At no point could it ever be an rvalue.
>
> You are trolling this mailing list. You are just proposing features for
> the sake of proposing features. At no point you have never considered if
> this makes any sense. You have absolutely no use case or justification
> for this, because it's not possible for it to ever be one.
> The whole thing is just nonsense.
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Frederick Virchanza Gotham via Std-Proposals <
> std-proposals_at_[hidden]>
> *Sent:* Sunday, March 24, 2024 7:23:53 PM
> *To:* std-proposals <std-proposals_at_[hidden]>
> *Cc:* Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
> *Subject:* [std-proposals] Forwarding refs for class template arg
> deduction
>
> Up until C++17, we had to use 'lock_guard' as follows:
>
> lock_guard<mutex> mylock(mymutex);
>
> But then C++17 came, and we could do:
>
> lock_guard mylock(mymutex);
>
> There's one weakness here though: If we want the constructor's parameters
> to be forwarding references, then we cannot do the following:
>
> template<typename T>
> class lock_guard {
> public:
>
> template<typename T>
> lock_guard(T &&arg)
> {
>
> }
> };
>
> But what if we had a new syntax whereby we could write:
>
> ^template^
>
> before the constructor, so that it would look something like:
>
> template<typename T>
> class lock_guard {
> public:
>
> ^template^
> lock_guard(T &&arg)
> {
>
> }
> };
>
> So now the constructor has forwarding references, and you can do:
>
> lock_guard mylock(mymutex):
>
> so that 'T' will be 'mutex&'. And if you do:
>
> lock_guard( move(mymutex) )
>
> then T will be 'mutex' in line with the rules for forwarding references.
>
> I thought of the need for this when writing my paper on std::elide:
>
> virjacode.com/papers/elide.htm
>
> If you scroll down to 'Possible Implementation', you'll see that I have a
> function called 'elide' which returns a type called 'elide_t'. I needed to
> have a separate function in order to retain whether the parameters were
> Rvalues or Lvalues -- it's not possible to retain this information with
> just the class. But with the new feature I'm proposing in this email, we
> could get rid of the function and just have the class by itself.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>