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

Fix wording around sort guarantees #38961

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
Contributor

bors commented Jan 25, 2017

📌 Commit e02f923 has been approved by alexcrichton

@bors
Copy link
Contributor

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
Contributor

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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