2 ms·

An important part there is: Most users will never call <=> themselves. However somebody implementing a type can implement a single function and the compiler wil

An important part there is: Most users will never call <=> themselves. However somebody implementing a type can implement a single function and the compiler will translate usage of <, <=, ==, !=< >=, > to the single function. Reduces boiler plate in the implementation. (Think about it - most implementations of > or < will often use the same logic already, spelling this out is "annoying"; mind that for performance reasons it can still be worthwhile to implement a == explicitly as equal comparison is often faster than ordering, but that's something the type designer can chose)

inetknght 7y ago
> Think about it - most implementations of > or < will often use the same logic already, spelling this out is "annoying"; mind that for performance reasons it can still be worthwhile to implement a == explicitly as equal comparison is often faster than ordering, but that's something the type designer can chose Yup. My C++ code would often include a `int T.compare(const T& a)` member function. Then any comparison operator would be custom written too -- but only to delegate to the custom compare and check its result. This one feature alone will eliminate several lines of boilerplate.
cogman10 7y ago
Do you have an example of when == would be faster than a comparison? I can't think of any case that would have any appreciable difference in speed. Is it mostly around eliminating branching logic? Wouldn't there be a good chance that might be inlined and optimized away anyways?
- johannes1234321 7y ago
  On case is string comparison. When implementing == I can shortcut if length doesn't matter the string can't be equal. When implementing <=> I however have to iterate in any case. (While there the question then is if the shortcut is really efficient, as the iteration might already stop on first character ...)

inetknght 7y ago

> Think about it - most implementations of > or < will often use the same logic already, spelling this out is "annoying"; mind that for performance reasons it can still be worthwhile to implement a == explicitly as equal comparison is often faster than ordering, but that's something the type designer can chose Yup. My C++ code would often include a `int T.compare(const T& a)` member function. Then any comparison operator would be custom written too -- but only to delegate to the custom compare and check its result. This one feature alone will eliminate several lines of boilerplate.

cogman10 7y ago

Do you have an example of when == would be faster than a comparison? I can't think of any case that would have any appreciable difference in speed. Is it mostly around eliminating branching logic? Wouldn't there be a good chance that might be inlined and optimized away anyways?

johannes1234321 7y ago
On case is string comparison. When implementing == I can shortcut if length doesn't matter the string can't be equal. When implementing <=> I however have to iterate in any case. (While there the question then is if the shortcut is really efficient, as the iteration might already stop on first character ...)