I'm not saying you shouldn't be able to implement both such that they're not coherent, I'm saying requiring implementing both when the system could provide one based on the other (as e.g. Haskell, Rust or Python do) is an unforced error and a pointless footgun.
I think it’s the other way. Providing one based on the other is a pointless footgun.
The experience doesn’t end when you’ve made machine code from your source. Developers debug stuff. Developers support their products, sometimes analyzing crash dumps.
The more magic is used in the compiler, the harder it is to debug and support software.
Sometimes that’s justified, e.g. in C# there’s substantial amount of compiler magic for generators and async functions. But these 2 features save substantial amount of code complexity.
Implementing != from == and > from < only provides minimal profit. The manual implementation is a single line method.
Another reason, C# is different language than Rust or Python. It has awesome support for OOP and runtime reflection. What should happen if you use reflection to get op_Inequality for a class where only == is defined? What should happen if you define == in a base class and != in a derived one?
>> C++ compiler needs to provide robust compile-time and run-time checks to tell programmers that things are wrong
> Hard to do without breaking backward compatibility, which is among the main reasons why we still write C++.
Although the language specification may need to preserve backwards compatibility, compilers can offer strictness warnings that go beyond that (e.g. -Wstrict). And the standards have deprecated and removed things as well. It’s not a straightjacket.
For the last 20 years, C++ standard library uses `operator <` for std::sort, and for building red black trees like std::map and std::set; `operator >` is not used.
Making this a warning would probably break too much existing code.
Well, you can use whatever extremities of strictness and year of standard for new code (mine is currently c++17 + pretty much every possible warning). And you can keep lower levels of warning for older, or third party code.
In the case of the standard library, the whole library is being hoisted to use <=> in c++ 20. Old code will still work with the latest library of course.
What we do is make a small shim to a more modern interface and then compile the shim, with the includes, in c++11 mode with whatever warnings disabled as necessary.
I know this doesn't work for everyone and we can't even do it with everything. But it helps a lot.
Hard to do without breaking backward compatibility, which is among the main reasons why we still write C++.
It’s done in C#. CS0216 forces you to implement operators in sets, e.g. can’t implement `==` without also implementing `!=` it won’t build otherwise: https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0216
And these warnings are printed for compatibility with containers: https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0660 https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0661