C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Manifold comparison operator

From: David Brown <david_at_[hidden]>
Date: Mon, 11 Sep 2023 08:57:50 +0200
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_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> 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.

Received on 2023-09-11 06:58:02