On 29.09.2016 18:41, Sai wrote:
>> I.e. you can overload '+' to do bad things. Yes, you can, and as I
>> replied upthread that can be done because there's no way to prevent
>> that while having operator overloading at all.
>>
>> But that is not justification for allowing such disasters for the
>> comparison operators. I.e. one weakness is not justification for
>> opening the door to all weakness.
>
> If I understand the issue correctly, one will not be able to overload
> <=, >, etc for symbolic math, like CAS (mimicking mathematica for
> example), how can I do it now?
>
> Wouldn't the current rules discourage someone from implementing CAS like
> library in D?
>
>

Not really, but it's annoying.

On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis wrote:
> The language can't stop you from doing at least some arbitrary stuff with them (like making + do subtraction), but the whole goal was for user-defined types to be able to act like the built-in types, and as such, it would make no sense to alter them towards being treated like symbols that you can do whatever you want with.

Having `+` do subtraction isn't something you'd normally see. It's not a use case that would normally exist.

Having `+` do addition, but do so in a database layer is a use case that actually may exist. The operator still behaves like a built-in type. It may perform addition as part of a SQL query, for example.

Whether the expression `a + b` is translated into machine language, or translated into SQL, both still perform addition. A value represented by `a` is added to a value represented by `b`. Whether `a` and `b` are variables in D, or columns in a database table is irrelevant.

And as it stands, D can already do this. It's the inability to perform an equivalent action for the expression `a > b`.

On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis wrote:
> The reality of the matter is that D's operator overloading was designed specifically so that you could overload the built-in operators to be used with your own types so that they could act like the built-in types. It was not intended or designed to allow for the symbols use for those operators to then be used for other arbitrary stuff that's unrelated to what they mean for the built-in types.

I repeat: Your thinking like this limits D's viability for real-world code.

Yes, I understand, the reason operator overloading works the way it does now is because members of the community wanted to arbitrarily limit programmers working in the language. Because they believed theirs was the singular appropriate way to use the language, to the exclusion of all others.

I'm opinionated too, but I also have the presence of mind to recognize that my opinions are not universal, and they are certainly no basis for imposing arbitrary limits upon another person's behavior.

On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis wrote:
> And there are plenty of folks who think that overloading operators to do stuff fundamentally different from how they work for the built-in types is bad practice and consider it to be an abuse of operator overloading. So, the fact that D limits that is going to be viewed as positive by many folks.

Let me see if I understand your thinking:

What you're saying is that because some people may not want to use a feature in a specific way, D should disallow anyone from using the feature in that way? That, somehow, contrary to logic, you believe this contributes positively to D's usability and appeal?

On Thursday, September 29, 2016 20:16:00 pineapple via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis
>
> wrote:
> > The reality of the matter is that D's operator overloading was designed specifically so that you could overload the built-in operators to be used with your own types so that they could act like the built-in types. It was not intended or designed to allow for the symbols use for those operators to then be used for other arbitrary stuff that's unrelated to what they mean for the built-in types.
>
> I repeat: Your thinking like this limits D's viability for real-world code.
>
> Yes, I understand, the reason operator overloading works the way it does now is because members of the community wanted to arbitrarily limit programmers working in the language. Because they believed theirs was the singular appropriate way to use the language, to the exclusion of all others.
>
> I'm opinionated too, but I also have the presence of mind to recognize that my opinions are not universal, and they are certainly no basis for imposing arbitrary limits upon another person's behavior.

Except that the limits aren't arbitrary. Walter designed D's overloaded operators for a specific purpose - to mimic the built-in operators. If you want to make them do something else, and you're able to do so with how they're designed, then that's your choice, but that's not what they're designed for, and there is no attempt to support it.

You could just as easily ask why D's overloaded operators don't support arbitrary operators, allowing you do stuff like opBinary!"#" to support # in your code and complain that the current limitation on that is arbitary. The feature _could_ have been made to do something like that, but that wasn't its intended purpose, and there are reasons why it's a bad idea, so that's not how D's operator overloading was designed.

The comparison operators have a specific purpose, and the functions for overloading them were designed with that in mind. It just so happens that that conflicts with what you want to do, but that doesn't mean that the limitation is arbitrary. Rather, code correctness and conciseness of code was valued, so they were overloaded using functions that could be used to derive those operators rather than explicitly overloading each operator individually. And because the ability to overload operators to do aribtrary stuff was never one of the goals of the design, the fact that having functions like opEquals and opCmp conflicted with the ability to overload each comparison operator to do arbitrary stuff was not considered to be a problem.

It's a design tradeoff that just doesn't happen to be in line with what you want to do.

Just because C++ overloaded operators in a way that happens to support doing arbitrary stuff with all of them doesn't mean that D needs to or that the restriction is arbitrary.

> On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis
>
> wrote:
> > And there are plenty of folks who think that overloading operators to do stuff fundamentally different from how they work for the built-in types is bad practice and consider it to be an abuse of operator overloading. So, the fact that D limits that is going to be viewed as positive by many folks.
>
> Let me see if I understand your thinking:
>
> What you're saying is that because some people may not want to use a feature in a specific way, D should disallow anyone from using the feature in that way? That, somehow, contrary to logic, you believe this contributes positively to D's usability and appeal?

There are plenty of folks who think that overloading operators to mean anything other than what they mean for the built-in types is bad practice. Walter seems to be in agreement with that. So, when he designed D's operator overloading, he did not attempt to support that. He didn't do a lot to prevent it either, but in cases where it made sense to derive multiple operators from a single function, he did so, even if it meant that you then couldn't overload those operators to mean something other than what they meant for the built-in types, because he considered what you got out of combining them was worth far more than trying to support what many think is bad practice.

t's not like Walter sat down and tried to prevent every misuse of operator overloading. He simply didn't choose a design that fully supports such misuse. Rather, he chose a design that better supports the intended use. The tradeoff just so happens to leave you without being able to do something that he considers to be bad practice, so he doesn't see it as a loss. And neither do I. But that wasn't even the primary goal of why the operators work they do. It's just a side effect of there being design goals that were better served by a design that happened to inhibit operator overloading abuse.

You'd have a much better argument if the language specifically did stuff to hobble the abuse of overloaded operators. It doesn't. It just doesn't implement operator overloading in a way that fully supports it. And Walter is clearly not in favor of implementing such a language "enhancement," because he thinks that it would just enable bad code, so I think that it's clear that it's not going to happen.

- Jonathan M Davis

On Thursday, 29 September 2016 at 20:16:00 UTC, pineapple wrote:
> I repeat: Your thinking like this limits D's viability for real-world code.

You're looking for https://www.perl.org/ That's a highly viable language, where you can do things like bury $[ = 1 somewhere in your code to change from 0-indexing to 1-indexing of arrays. They take pride in unpredictable, unreadable code.

On Thursday, 29 September 2016 at 22:27:50 UTC, bachmeier wrote:
> You're looking for https://www.perl.org/ That's a highly viable language, where you can do things like bury $[ = 1 somewhere in your code to change from 0-indexing to 1-indexing of arrays. They take pride in unpredictable, unreadable code.

This is not at all relevant to the current argument.

On Thursday, 29 September 2016 at 22:37:51 UTC, Minty Fresh wrote:
> On Thursday, 29 September 2016 at 22:27:50 UTC, bachmeier wrote:
>> You're looking for https://www.perl.org/ That's a highly viable language, where you can do things like bury $[ = 1 somewhere in your code to change from 0-indexing to 1-indexing of arrays. They take pride in unpredictable, unreadable code.
>
> This is not at all relevant to the current argument.

I see

On Thursday, September 29, 2016 22:37:51 Minty Fresh via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 22:27:50 UTC, bachmeier wrote:
> > You're looking for https://www.perl.org/ That's a highly viable language, where you can do things like bury $[ = 1 somewhere in your code to change from 0-indexing to 1-indexing of arrays. They take pride in unpredictable, unreadable code.
>
> This is not at all relevant to the current argument.

Except that it kind of is. It's an example of a language allowing you to mess with too much and make it so that it doesn't function as expected, which is what happens when you overload operators to act in a way inconsistent with how they work with the built-in types. The perl example is more extreme, but the point still stands that having normal, common constructs operate in a way that's inconsistent with how they normally work tends to make code harder to read and maintain. Certainly, it can result in very unexpected behavior when mixing it with generic code that uses those operations.

- Jonathan M Davis

On Thu, 29 Sep 2016 17:50:54 -0700, Jonathan M Davis via Digitalmars-d wrote:
> Except that it kind of is. It's an example of a language allowing you to mess with too much and make it so that it doesn't function as expected, which is what happens when you overload operators to act in a way inconsistent with how they work with the built-in types.

The perl example is a line of code buried somewhere that changes the meaning of the rest of the code. Operator overloading is restricted to a specific user-defined type. With such a dramatic difference in the scope of the change, the analogy is useless.

On Thu, 29 Sep 2016 10:41:38 +0200, Timon Gehr wrote:

> On 29.09.2016 06:15, Walter Bright wrote:
>> On 9/28/2016 1:40 PM, Timon Gehr wrote:
>>> (This is NOT expression templates.)
>>
>> Right, but it's an enabler of expression templates. Discussion of more
>> powerful operator overloading cannot be divorced from expression
>> templates, and once ETs are in we'll be stuck with them forever.
>> ...
> 
> They work today, just not with comparison operators.

To take it the other way, D could enforce that the return type of arithmetic operators is compatible with at least one of the operands -- by implicit cast or constructor or being the same type. Wouldn't that be fun?