I don't understand why we need to prevent std::elide from becoming a constructor argument. In fact I have use cases exactly where I want std::elide (or its equivalent) to be an argument to a constructor with a single argument.

If this is trying to address the problem of overly-permissive unary template constructors I think that's a problem of class design, not something that should be addressed at the language level.

What we want, if anything, is a way to prevent std::elide from being deduced from a constructor call as a class template argument via CTAD, but there are library solutions to that problem.

Thanks,

--Robert
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, June 3, 2024 17:35
To: std-proposals_at_[hidden] <std-proposals_at_lists.isocpp.org>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: Re: [std-proposals] std::elide

On Fri, May 31, 2024 at 4:12 PM Thiago Macieira wrote:
>
> A prvalue is a special type of rvalue. What you're saying is that rvalue-ref
> functions can only accept xvalues but not prvalues, though that's patently
> false.
<snip>
> Given that your introduction section contains such a blatant absurdity, either
> your paper is entirely wrong or you're using wrong terms to mean what you want
> to mean. I didn't read the rest.


I've corrected the wording and amended the paper. Here it is:

      http://www.virjacode.com/papers/prvalue_params.htm

Here's the list of changes:

      * Syntax changed from ^^ to &&&.
      * Wording of value categories corrected (i.e. XRvalue, PRvalue).
      * Implementation in x86_64 assembler for Linux, Apple, FreeBSD.


> I did notice you're still using std::mutex in your examples, though. STOP
> DOING THAT. Anyone reading the paper will again go into the discussion of how
> returning a mutex is pointless. Find another, real type that is immovable but
> makes sense to return.


I've been able to devise a regex to detect the people who dislike the
locked mutex example:

      T[h]{0,1}iago

I'm not willing to adjust the parameters of common sense to
accommodate two people who cannot see the woods for the trees.

Thiago, As árvores não deixam ver a floresta.
Tiago, Ik zie door het bos de bomen niet meer.

Anyway . . . back to talking about the class, std::elide. If we don't
include the change to the core language, then it will work with some
classes and not with others -- and that's not good enough in my
opinion. It should work with all classes, even the ones which have an
accept-anything constructor.

We need to devise some sort of way of preventing an "std::elide"
object from becoming an argument to a constructor which has exactly
one parameter. My paper suggests adding a short paragraph under "When
template instantiation will fail", however there are other
possibilities, such as marking the conversion operator:

    template<typename T>
    class elide {
        operator T() priority
        {
        }
    };

When the compiler sees a conversion operator marked as 'priority', it
invokes the conversion operator instead of allowing the class itself
to become the parameter to a constructor. I'm just throwing ideas out
there. Anyone got any other ideas for how to prevent std::elide from
becoming a constructor parameter?
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals