Skip to content

Fix wording around sort guarantees #38961

New issue

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

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

Already on GitHub? # to your account

Merged
merged 4 commits into from
Jan 26, 2017
Merged

Conversation

steveklabnik
Copy link
Member

Fixes #38524

/cc @rust-lang/libs @stjepang

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You changed the documentation of sort(), but forgot about sort_by and sort_by_key :)

The current changes will resolve the discussed normativity issue, which is good. However, I'd like to push for higher quality documentation while we're at it.

I left a few suggestions on how to do that. We don't need long boring walls of text. Just a few points on the key characteristics of this particular implementation.

/// temporary storage half the size of `self`.
/// This sort is stable and `O(n log n)` worst-case.
///
/// # Current Implementation
Copy link

@ghost ghost Jan 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just nitpicking here: lowercase "implementation" would be more consistent with other docs in libstd.

///
/// # Current Implementation
///
/// The current implementation allocates temporary storage half the size of `self`.
Copy link

@ghost ghost Jan 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we have a section about the current implementation, this would be a great chance to expand a little bit. For inspiration, see Java's docs starting from "Implementation note".

I would like to see several things pointed out:

  1. That this sort is an adaptation of Tim Peters' timsort with this link.
  2. That this is an iterative sort.
  3. That this is an adaptive sort. Again, Java has a nice explanation: "It is well-suited to merging two or more sorted arrays: simply concatenate the arrays and sort the resulting array."

@@ -1041,8 +1041,11 @@ impl<T> [T] {

/// This is equivalent to `self.sort_by(|a, b| a.cmp(b))`.
///
/// This sort is stable and `O(n log n)` worst-case, but allocates
/// temporary storage half the size of `self`.
/// This sort is stable and `O(n log n)` worst-case.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's explain what "stable" means, since it can be a confusing term for people unfamiliar with it.
Java's docs have a nice concise explanation: "This sort is guaranteed to be stable: equal elements will not be reordered as a result of the sort."

@ghost
Copy link

ghost commented Jan 11, 2017

One more thing I noticed...

sort_by has this explanation: Sorts the slice, in place, using compare to compare elements.
I'd like to see "in place" gone because it sounds like sort_by does not allocate, which is incorrect.

sort_by_key has this explanation: Sorts the slice, in place, using f to extract a key by which to order the sort by.
We again have "in place" but this time it at least makes sense - it's trying to say that sort_by_key does not do decorate-sort-undecorate.
However, I'm not too happy with "in place" here either and would prefer different wording.

@steveklabnik
Copy link
Member Author

@brson @alexcrichton are we going to backport this? If so, I can wrap it up right now, but if not, I'd rather not drop everything to do so. know you wanted to get beta done by today

@alexcrichton
Copy link
Member

I'd be ambivalent about a backport. I wouldn't advocate for it but I also wouldn't say no.

@alexcrichton
Copy link
Member

@steveklabnik looks like there's a whitespace error here, but other than that r=me

@alexcrichton alexcrichton self-assigned this Jan 19, 2017
@alexcrichton alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jan 19, 2017
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Collaborator

bors commented Jan 25, 2017

📌 Commit e02f923 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Jan 26, 2017

⌛ Testing commit e02f923 with merge 6991938...

bors added a commit that referenced this pull request Jan 26, 2017
@bors
Copy link
Collaborator

bors commented Jan 26, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 6991938 to master...

@bors bors merged commit e02f923 into rust-lang:master Jan 26, 2017
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants