3 ms·

You are not arguing in good faith but just in case I will point out what you are missing: 1)Implicit operator overload is a bad design in case of pointers and

You are not arguing in good faith but just in case I will point out what you are missing: 1)Implicit operator overload is a bad design in case of pointers and objects because a.b and a->b are both readable, easy to type and short. 2)Integer promotion is not as simple because requiring explicit promotion makes a holy unreadable mess out of your code in the simplest of cases. 2) is demonstrated many times by mongo code lines in Java with all the explicit casts. This is also the reason Python has implicit promotion for its number type. You sacrifice something to get something unlike in 1) where you only lose for no gain what so over.

masklinn 3y ago
> You are not arguing in good faith You're just not being honest. > 1)Implicit operator overload is a bad design in case of pointers and objects because a.b and a->b are both readable, easy to type and short. That's just a baseless assertion. Here I can do the same: implicit overloading is a great design in case of pointers and objects because a.b is always unambiguous and uniform, and -> is a harder to read and type extra operator which has no justification. And then obviously your assertion can be used exactly the same way to similarly assert that every numeric type should have its own set of arithmetic operators, after all u4+ is also readable, easy to type, and short. > 2)Integer promotion is not as simple because requiring explicit promotion makes a holy unreadable mess out of your code in the simplest of cases. Integer promotion is much simpler because it's literally a never-ending source of bugs. > This is also the reason Python has implicit promotion for its number type. Python does not have implicit promotion for its number type, at best Python 2 had that for performance reasons (definitely not "mongo code lines with all the explicit casts" which it could not care less about), and in reality that was not even the case because it does not corrupt your data upfront as C does.

masklinn 3y ago

> You are not arguing in good faith You're just not being honest. > 1)Implicit operator overload is a bad design in case of pointers and objects because a.b and a->b are both readable, easy to type and short. That's just a baseless assertion. Here I can do the same: implicit overloading is a great design in case of pointers and objects because a.b is always unambiguous and uniform, and -> is a harder to read and type extra operator which has no justification. And then obviously your assertion can be used exactly the same way to similarly assert that every numeric type should have its own set of arithmetic operators, after all u4+ is also readable, easy to type, and short. > 2)Integer promotion is not as simple because requiring explicit promotion makes a holy unreadable mess out of your code in the simplest of cases. Integer promotion is much simpler because it's literally a never-ending source of bugs. > This is also the reason Python has implicit promotion for its number type. Python does not have implicit promotion for its number type, at best Python 2 had that for performance reasons (definitely not "mongo code lines with all the explicit casts" which it could not care less about), and in reality that was not even the case because it does not corrupt your data upfront as C does.