This was removed with the smartmatch removal, but I suspect it's better to silently leave it in for two reasons:
Firstly, I suspect that there are lots of classes that overload several operators. Them having to conditionally set one of their overloads complicates them without much benefit. Silently allowing them seems like the friendliest option. If they're truly reliant on it the tests will show it anyway.
Secondly, I am working on backwards compatability module, and that will require ~~ overloading one way or another. This would be easiest solution to that. The alternative would be to make the list of operators customizable, which may be good idea regardless of adding smartmatch back in.
This was removed with the smartmatch removal, but I suspect it's better to silently leave it in for two reasons:
Firstly, I suspect that there are lots of classes that overload several operators. Them having to conditionally set one of their overloads complicates them without much benefit. Silently allowing them seems like the friendliest option. If they're truly reliant on it the tests will show it anyway.
Secondly, I am working on backwards compatability module, and that will require
~~overloading one way or another. This would be easiest solution to that. The alternative would be to make the list of operators customizable, which may be good idea regardless of adding smartmatch back in.