On 3/29/25 04:52, Jonathan M Davis wrote:
> Yes, and part of my point is that for a number of operators, that's a
> problem, because it would mean trying to overload the default behavior of an
> operator via a symbol which may or may not be imported. Maybe it would be
> okay with something like the arithmetic operators, but for something like
> toHash or opCast, it could cause serious problems.
> 
> For at least some of these operators, the language is designed with the idea
> that they are either always present, or the compiler will generate code on
> its own to use them if they're not, and those absolutely must be part of the
> type, or we'll get all kinds of iconsistencies and hard-to-track-down
> behaviors. Trying to have them be external would be like trying to have copy
> constructors declared externally and be affected by imports.

Well, UFCS cannot override a member function, so there are ways to solve this consistently.

On 3/29/25 07:09, Walter Bright wrote:
> Thank you, Jonathan. You've said it well. Let's give an example:
> 
> ```
> struct A { int a; alias this = a; }
> 
> struct B { int b; alias this = b; }
> 
> void test()
> {
>      A a;
>      B b;
>      int i = a + b;
> }
> ```
> 
> This compiles today. The statement is replaced with:
> ```
>      int i = a.a + b.b;
> ```
> Now let's suppose some other module is imported, and it declares:
> ```
> int OpAdd(A a, B b) { return 7; }
> ```
> and now:
> ```
>      int i = 7;
> ```
> Don't we have the classic hijacking problem we've worked hard to avoid in D?

Absolutely not.

```
import std.stdio;

struct S{
    void foo(){ writeln("member"); }
}

struct T{
    S s;
    alias this=s;
}

void foo(S s){ writeln("ufcs"); }

void main(){
    T t;
    t.foo();
}
```

Prints "member" (of course).

Your case is not different.

In terms of implementation, just add `opBinary` (and the other operator names) to `int`, and it will just work. This should be done anyway, btw. Much nicer to be able to consistently use `opCmp` in generic code. Actually getting this right and avoiding runtime blowup exponential in the opCmp depth is annoying at the moment and may not be obvious to everyone.

The only hijacking case with UFCS is if the type adds a member. That may hijack existing UFCS calls. This exists already and is hard to avoid because people are relying on this behavior.

Anyway, none of this has anything to do with operators if the language is designed and implemented in an orthogonal fashion.

On 3/29/25 17:07, Nick Treleaven wrote:
> 
>> ```
>> import std.stdio;
>>
>> struct S{
>>     void foo(){ writeln("member"); }
>> }
>>
>> struct T{
>>     S s;
>>     alias this=s;
>> }
>>
>> void foo(S s){ writeln("ufcs"); }
> 
> I think `foo` should be `void foo(T t)`,

You are correct, it should be. This is closer to the original example.

> but it still prints "member" anyway :-)

Yes. UFCS never overrides a matching member function, no matter how well the UFCS function matches. UFCS is not even attempted if a call can be resolved via member function.

On 3/29/2025 9:25 AM, Timon Gehr wrote:
> Yes. UFCS never overrides a matching member function, no matter how well the UFCS function matches. UFCS is not even attempted if a call can be resolved via member function.

That's correct. The issue brought up in my preceding post is *should* operators be treated as if they were functions? Or are they special? I've seen what happens when they are treated as functions. People write code that looks like conventional C++ code, but with the operators overloaded to do something utterly different. They'd write articles saying how cool this was. I had the opposite reaction.

There are a number of deliberate characteristics in D that discourage writing incomprehensible code, like no macros and no version algebra. The operator overloading capability in D is deliberately restrictive, to make it harder to do non-arithmetic things with it.

With functions, there are no implicit expectation of what is does, we all know that. But the expectation with operators is `a+b` does an addition. (That's why D uses ~ for concatenation, not +) If the user suspects that it does something else, at least he can visit the type declaration to see if it was repurposed.

But overloading operators with freestanding functions? It becomes a nightmare with non-trivial programs.

On 3/29/2025 9:31 AM, Steven Schveighoffer wrote:
> One reason why I rarely propose things in D these days is because the parade of C++ bogey-straw-men come out every time, which have nothing to do with the proposal.

See my reply to Timon's response.

There's got to be a high bar for adding new features, each one adds more cognitive load to anyone trying to understand the language.

Nobody understands C++ the language, and far too many C++ code bases are incomprehensible.

I can empathize your frustration. My attempts to make bitfields part of the language are still languishing. Using them in my own work would make for significantly simpler and more readable code.

Fortunately, C++ left bitfields intact :-)

On Saturday, 29 March 2025 at 19:06:18 UTC, Walter Bright wrote:
> On 3/29/2025 9:31 AM, Steven Schveighoffer wrote:
>> One reason why I rarely propose things in D these days is because the parade of C++ bogey-straw-men come out every time, which have nothing to do with the proposal.
>
> See my reply to Timon's response.
>
> There's got to be a high bar for adding new features, each one adds more cognitive load to anyone trying to understand the language.


I suppose one could always add Algol 68 like operator functions, such that one could then write something like:

```
int something(int a, int b) {

   return a plus b;
}
```

Assuming one could figure out a syntax for declaring 'plus', and then avoid it being backward incompatible...