Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

N4475: Default comparisons #32

Closed
Morwenn opened this issue Nov 24, 2015 · 2 comments
Closed

N4475: Default comparisons #32

Morwenn opened this issue Nov 24, 2015 · 2 comments

Comments

@Morwenn
Copy link
Owner

Morwenn commented Nov 24, 2015

N4475 and a few related papers discuss the idea of generating the operators ==, !=, <, >, <= and >= be defaults for classes, with "usual" semantics (too long to explain here) and under some specific conditions.

As every paper discussing comparison, it might have an influence on sorting operations, but how? It seems that a generated operator< would perform a lexicographic comparison over every member of the class to compare, in declaration order. If every member of a class is taken into account, then a basic sort over the structure is stable under some conditions:

  • The comparison is a total order.
  • The type doesn't have equivalent elements (looking at you foating point numbers).
  • The iterators don't have observable side effects.
  • The copy/move operations on the type don't have observable side effects.

Provided the standard library adds type traits such as is_trivially_less_than_comparable to help identify such classes, it may be possible to make stable sorts use equivalent unstable sorts when they exist since the latter should be more performant. It relates to issue #21 but more work has to be done to identify when such a trick is usable and whether it is worth it.

@Morwenn
Copy link
Owner Author

Morwenn commented Jun 24, 2016

Default comparisons just got nuked from orbit during the Oulu meeting. If they ever come back, they will probably be opt-in and, even then, it is not guaranteed than any type traits might be proposed to detect them. We can safely close this issue for now, and maybe reopen it in a few years if needed.

I doubt we will ever have to reopen it.

@Morwenn Morwenn closed this as completed Jun 24, 2016
@vendethiel
Copy link

:rip:

@Morwenn Morwenn added no-future and removed future labels Jun 24, 2016
@Morwenn Morwenn mentioned this issue Feb 22, 2019
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants