[SUGGESTION] Allow use of named operators on non-class types

[orent]

Expression that flow from left to right without evaluation order jumping around are easier to read and write and less error prone. This is probably one of the reasons for the success of the shell pipe. The use of postfix operators in Cpp2 makes it easier to maintain such strict left-to-right order without requiring the use of extraneous parentheses. It also combines particularly well with UFCS.

But this does not work with the infix operators. While compatibility with math notation is important, having an alternative way to perform these operations without triggering the usual operator evaluation precedence rules would be useful.

The most natural alternative spelling for the infix operators is .operator★(). This actually already works in C++ and therefore in Cpp2. It is possible to rewrite g(f(a)+b) as the pure left-to-rightf(a).operator+(b).g() - but it only works when the objects are class types. This does not work with ints, for example.

Suggestion:

• Make a.operator★(b) always equivalent to ((a) ★ (b))

Possible implementations:

• Add .operator★() methods to the builtin non-class types
• Make operator★() global builtin functions that can be used either in the form operator★(a,b) or UFCSed to a.operator★(b)

The latter seems simpler and would just require translating operator★(a,b) to standard template functions cpp2::operator_name(a,b).

[JohelEGP]

A library-based solution can read much nicer (https://cpp2.godbolt.org/z/13Gq8Gn4q):

#include <boost/hana.hpp>
using namespace boost::hana;
main: () = {
  f := :(x) -> _ = x + x;
  g := :(x) -> _ = x * x;
  a := 1;
  b := 2;
  std::cout << f(a).plus(b).g() << '\n';
}

Program returned: 0
16

[orent]

C++ already has a way to spell operators as methods. And it already works in both C++ and Cpp2 - just inconsistently. Closing this inconsistency gap decreases the total conceptual footprint of the language, not increases it. It might increase cppfront line count, but that is not what counts.

[msadeqhe]

I think this inconsistently should be fixed if there isn't any good reason behind it by either one of the following ways:

• Allow to spell operators as methods on built-in types (e.g. allow 5.operator+(10)).
• Disallow to spell operators as methods on user-defined types (e.g. disallow a.operator+(b)).

Less inconsistency leads to less pages for the language specification.

[SebastianTroy]

Can we lose the operator keyword entirely somehow? On 20 May 2023 12:27:49 Sadeq ***@***.***> wrote: I think this inconsistently should be fixed if there isn't any reason behind it by either one of the following ways: * Allow to spell operators as methods on built-in types (e.g. allow 5.operator+(10)). * Disallow to spell operators as methods on user-defined types (e.g. disallow a.operator+(b)). Less inconsistency leads to less pages for the language specification. — Reply to this email directly, view it on GitHub<#430 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQKCWEUMZUMS24AT7O3XHCTC3ANCNFSM6AAAAAAXY3WOIA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[msadeqhe]

Good Idea. Yes. One possible option is to use this instead of operator.

For example, operator overloading inside type definition (member functions):

Xyz: type = {}

Abc: type = {
    // Unary Prefix Operator Plus
    // operator+: (this) -> Abc = {}
    this+: (this) -> Abc = {}

    // Binary Operator Plus
    // operator+: (this, that: Xyz) -> Abc = {}
    this+: (this, that: Xyz) -> Abc = {}
}

For example, operator overloading outside type definition (non-member functions):

Xyz: type = {}

Abc: type = {}

// Unary Prefix Operator Plus
// operator+: (a: Abc) -> Abc = {}
this+: (a: Abc) -> Abc = {}

// Binary Operator Plus
// operator+: (a: Abc, b: Xyz) -> Abc = {}
this+: (a: Abc, b: Xyz) -> Abc = {}

In this way, if this is used within the name of declaration (e.g. the left side of :), it would be treated as a keyword similar to the meaning of operator.

[SebastianTroy]

Hmmm, if a keyword is required, operator is more expressive than this, I was wondering why the word operator was needed at all, but maybe for parsing reasons? On 20 May 2023 14:08:54 Sadeq ***@***.***> wrote: Good Idea. Yes. One possible option is to use this instead of operator. For example, operator overloading inside type definition (member functions): Xyz: type = {} Abc: type = { // Unary Prefix Operator Plus // operator+: (this) -> Abc = {} this+: (this) -> Abc = {} // Binary Operator Plus // operator+: (this, that: Xyz) -> Abc = {} this+: (this, that: Xyz) -> Abc = {} } For example, operator overloading outside type definition (non-member functions): Xyz: type = {} Abc: type = {} // Unary Prefix Operator Plus // operator+: (this) -> Abc = {} this+: (a: Abc) -> Abc = {} // Binary Operator Plus // operator+: (this, that: Xyz) -> Abc = {} this+: (a: Abc, b: Xyz) -> Abc = {} In this way, if this is used within the name of declaration (e.g. the left side of :), it would be treated as a keyword similar to operator. — Reply to this email directly, view it on GitHub<#430 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQKFUC3X52E4WMCVW5TXHC653ANCNFSM6AAAAAAXY3WOIA>. You are receiving this because you commented.Message ID: ***@***.***>

[msadeqhe]

By the way, type is a good condidate to replace operator too.

For example, operator overloading inside type definition (member functions):

Xyz: type = {}

Abc: type = {
    type+: (this) -> Abc = {}
    type+: (this, that: Xyz) -> Abc = {}
}

For example, operator overloading outside type definition (non-member functions):

Xyz: type = {}
Abc: type = {}

type+: (a: Abc) -> Abc = {}
type+: (a: Abc, b: Xyz) -> Abc = {}

And you're right. operator is familiar and more expressive than this and type about the code.

[orent]

Can we lose the operator keyword entirely somehow?

Why? Keywords can aid readability. Avoiding or reducing keywords should not be a goal by itself without other demonstrable benefits.

“How do we make this as different as possible from C++1” is also a non-goal.

[SebastianTroy]

All true points, i was just wondering if it was necessary, whether we could just allow function names to just be symbols, but thinking further I suppose operators really are special because they can be called without . or () On 20 May 2023 14:37:18 orent ***@***.***> wrote: Can we lose the operator keyword entirely somehow? Why? Keywords can aid readability. Avoiding or reducing keywords should not be a goal by itself without other demonstrable benefits. “How do we make this as different as possible from C++1” is also a non-goal. — Reply to this email directly, view it on GitHub<#430 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQL6MYAOMVN4MVLEWYDXHDCIJANCNFSM6AAAAAAXY3WOIA>. You are receiving this because you commented.Message ID: ***@***.***>

[JohelEGP]

I think this inconsistently should be fixed if there isn't any good reason behind it by either one of the following ways:

* Allow to spell operators as methods on built-in types (e.g. allow `5.operator+(10)`).

* Disallow to spell operators as methods on user-defined types (e.g. disallow `a.operator+(b)`).

Less inconsistency leads to less pages for the language specification.

I think it's because they're not functions.
Suppose you can spell them.
The next inconsistency pops up: you can't take their address, because they're not functions.
This will just go on.
So take a step back and ask:
Is bridging the gap between UDTs and fundamental types a goal for Cpp2? Should it?
Try filling the suggestion template with that as theme.

Note that C++20 has this for UDTs, too.
A type with only operator== will have an expression using operator != rewritten in terms of ==.
Attempting to access or take the address of operator!= won't work on such a type.

Also, I don't think we should take away the possibility of naming those functions
(yes, operators are just functions)
just for inconsistency with fundamental types.
Why? Just so I have to use library wrappers?
Why use std::plus<my_type> when my_type::operator+ suffices?
See https://quuxplusone.github.io/blog/2022/10/16/prefer-core-over-library/.

[msadeqhe]

I think it's because they're not functions.

...

Also, I don't think we should take away the possibility of naming those functions
(yes, operators are just functions)
just for inconsistency with fundamental types.

I've emphased two parts from your comment. IMO that's the inconsistency I'm talking about, either they are functions, or they are not. BTW they are operators which works on both built-in types and UDTs.

[jcanizales]

Floating point division is a function with an address, on NVidia GPUs.

[JohelEGP]

Not from the perspective of the C++ abstract machine.

[jcanizales]

Fair. It wouldn't be a breaking change to make them addressable, given that current C++ code cannot take those addresses. It's a bit of a fiction to present built-in functions like those the same as user-defined functions. But it can be convenient for the user. Analogously to how presenting built-in types as user-defined types is convenient when it comes to UFCS.