On 08/09/2023 23:32, Arthur O'Dwyer via Std-Proposals wrote:
> On Fri, Sep 8, 2023 at 4:48 PM David Brown via Std-Proposals
> <std-proposals@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>>
> wrote:
>
>
>     It should even be possible to write something like :
>
>              if (var <= none_of(opt1, opt2, opt3)) ...
>
>     by having "none_of" return a type X for which there is an operator <=
>     (LHS, X) overload.
>
>     But I would not recommend standardising on such a syntax unless people
>     agreed to use a similar syntax for many new features.  And maybe it
>     would be best to have a new operator specifically for such purposes -
>     perhaps a two operand ~.
>
>
> Or the previously proposed syntactic sugar |>, where `x |> y(z)` would
> be rewritten in the front end into `y(x,z)` even when `y(z)` wouldn't be
> well-formed on its own.

I hadn't noticed that proposal, but yes, it would fit here.  (Was there
also a proposed "x <| y(z)" meaning "y(z, x)" ? 

I think that would be
more natural in many cases, though the ordering of |> is definitely
better in this particular situation.)

>
> LLVM's codebase already uses named methods for this sort of thing in
> several places; e.g.
>      if (!Current.isOneOf(tok::comment, tok::caret)) ...
> and I think that's a fine solution in general.
>
> Meanwhile, OP's proposed "after" snippet:
>        const OverloadedOperatorKind OOK = FD->getOverloadedOperator();
>        if (OOK [!] OO_EqualEqual, OO_ExclaimEqual, OO_Less,
> OO_LessEqual, OO_Greater, OO_GreaterEqual, OO_Spaceship)
>          return false;
> could actually be written today, using LLVM's existing codebase, as:
>      const OverloadedOperatorKind OOK = FD->getOverloadedOperator();
>      if (CXXOperatorCallExpr::isComparisonOp(OOK))
>        return false;
> and then it just becomes a matter of maybe moving that utility function
> somewhere with a better name (like, I don't know, dump it in Sema with
> everything else).
> I definitely /don't/ think OP's "after" snippet is an improvement over
> LLVM's status quo. I think it'd be worse.
>

Agreed.



--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals