On Mon, 25 Mar 2024, 06:01 Gašper Ažman via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> 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.
>

At some point we do have to accept that this poster is just spamming the
list with half baked nonsense.



> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>