C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Forwarding refs for class template arg deduction

From: Tiago Freire <tmiguelf_at_[hidden]>
Date: Sun, 24 Mar 2024 18:58:42 +0000
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<http://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.



Received on 2024-03-24 18:58:45