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
