D1 operator overloads have been deprecated.

[aliak]

On Sunday, 14 July 2019 at 05:27:28 UTC, Bert wrote:
> On Friday, 12 July 2019 at 15:21:10 UTC, FeepingCreature wrote:
>> On Friday, 12 July 2019 at 13:42:35 UTC, Bert wrote:
>>> um, the OP said "works with virtual functions/inheritance". 
>>> When are people going to learn that aliases are not virtual 
>>> and have nothing to do with preserving inheritance structure?
>>>
>>
>> You're misunderstanding.
>>
>> import std.stdio;
>>
>> abstract class X
>> {
>>     abstract X opAddImpl(X rhs);
>>     alias opBinary(string op:"+") = opAddImpl;
>> }
>>
>> class C : X{
>>     int x;
>>     this(int x){ this.x=x; }
>>     override C opAddImpl(X rhs){
>>         return new C(x+(cast(C) rhs).x);
>>     }
>> }
>> void main(){
>>     X a=new C(1),b=new C(2);
>>     writeln((cast(C) (a+b)).x);
>> }
>
>
> This works but now requires modifying the entire oop structure 
> to conform. This is now how oop is suppose to work or good 
> design decisions. We are talking about a pre-existing oop 
> design that might be 100's of classes in size.
>
> It's all fine and dandy when you are designing something from 
> scratch but since D1 essentially does this anyways, what's the 
> point of depreciating it then requiring it?
>
> https://digitalmars.com/d/1.0/operatoroverloading.html
>
> import std.stdio;
>
> abstract class X
> {
>     //abstract X opNeg(); // D1
>     abstract X opNegImpl(); // D2
>     alias opUnary(string op : "-") = opNegImpl; // D2
> }
>
> class C : X
> {
>     int x;
>     this(int x) { this.x = x; }
>     //override C opNeg(){ return new C(-this.x); } D1
>     override C opNegImpl() { return new C(-x); }
>
> }
>
> void main()
> {
>     X a = new C(1), b = new C(2);
>     writeln((cast(C)(-b)).x);
> }
>
>
>
> So, all that has been achieved is allowing one to use their own 
> base function names. A whole shit load of code is going to be 
> broke SIMPLY to remove the default opXXX names... names that 
> would rarely be used in any code for any other purpose 
> anyways(I've never in my live used an id starting with op that 
> was not meant to be used as an operator).
>
> Absolutely nothing is achieved if the only issue is "there are 
> "two" ways of doing it" as J.D. says.
>
>
> In the new way we have to have an alias redirector and the 
> function rather than just the function. All we end up getting 
> is freeing a member id name and a whole lot of broken code.

I'm curious where you get the "whole shit load of code is going 
to be broken" part?

And what do you suggest, that D keep supporting all its legacy? 
Or is it "just this one"? You can think that it's just one little 
feature but it's not - it's a lot of small features that are 
duplicated, that have to be maintained, that get bug reports 
because they are supposed to be working, and that actively hinder 
the development and solidifying of more useful features and 
features that supercede older features.  Bloat is bad.