Skip to content

Added Self where possible #29965

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

Closed
wants to merge 3 commits into from
Closed

Added Self where possible #29965

wants to merge 3 commits into from

Conversation

cmlsharp
Copy link

In this commit, I added Self as the return value for implementations that returned their own type as it seems much more readable IMO. Additionally for the implementations of Iterator and IntoIter, I used Self::Item and Self::IntoIter

EDIT: This is in the LinkedList implementation specifically

In this commit, I added `Self` as the return value for implementations that returned their own type as it seems much more readable IMO. Additionally for the implementations of Iterator and IntoIter, I used Self::Item and Self::IntoIter
@rust-highfive
Copy link
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @gankro (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@alexcrichton
Copy link
Member

Thanks for the PR! This may want to hold off, however, for a stylistic guideline on the usage of Self within the standard library. I believe the usage can affect how the documentation is rendered, and it's arguably clearer in some circumstances to not have to go up and look at what Self is.

@alexcrichton alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Nov 20, 2015
@cmlsharp
Copy link
Author

That's understandable. Does this stand even in implementations of the Iterator trait as the declaration of next() is supposed to return Option<Self::Item> (which is arguably looks better than Option<&'a A. Additionally, there were a few lines where private functions which had a return type of Option<Box<Node<T>>>. Should I submit another PR with that changed to Link<T> and with the private impls (e.g. Rawlink<T>) using Self ?

Just out of curiosity, would it be possible to have rustdoc automatically display Self as the underlying type in the documentation?

@Gankra
Copy link
Contributor

Gankra commented Nov 21, 2015

i'm a big fan of Self, and think all of these uses are uncontroversial.

@Gankra Gankra closed this Nov 21, 2015
@Gankra
Copy link
Contributor

Gankra commented Nov 21, 2015

Oops!

@Gankra Gankra reopened this Nov 21, 2015
@cmlsharp
Copy link
Author

If there ever is a consensus on the style for Self, I'd be happy to do this for more than just LinkedList. It's pretty easy and it gives me an excuse to look through the standard library which makes me a better Rust programmer.

@therustmonk
Copy link
Contributor

@gankro Does it affect on compilation speed for users' code?

@Gankra
Copy link
Contributor

Gankra commented Nov 21, 2015

I would be shocked if it showed up in compilation times, as it is trivial to desugar Self by looking at the parent impl block.

@liigo
Copy link
Contributor

liigo commented Nov 23, 2015

Self is less clear in semantic than concrete type. When users see a Self, they always ask/think "what is Self".

@Gankra
Copy link
Contributor

Gankra commented Nov 23, 2015

All of these changes are to standard trait implementations (so documentation/confusion isn't an issue, it's just DRY) or to private internals of code I'm one of the primary maintainers of (so documentation isn't an issue, and I believe it makes the code more simple).

As such I'm accepting these changes.

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Nov 23, 2015

📌 Commit 44500c8 has been approved by Gankro

@bors
Copy link
Collaborator

bors commented Nov 23, 2015

⌛ Testing commit 44500c8 with merge e77df19...

@Gankra
Copy link
Contributor

Gankra commented Nov 23, 2015

@bors r-

Actually LinkedList::new/append/split_off are being updated here, so those are actual things worth discussing.

@cmlsharp
Copy link
Author

If I may contribute my two cents. Upon further review I think Self should be used in the return types of methods (e.g. new()) but not in the arguments list (e.g. in append()). Here is what the documentation would look like: Screenshot

Here's my reasoning: Self makes code less redundant. Its meaning is self-evident and IMHO looks much cleaner. However, the fact that it looks so similar to self, means that replacing the concrete type with it in function arguments could potentially be confusing.

@bors
Copy link
Collaborator

bors commented Nov 25, 2015

☔ The latest upstream changes (presumably #30017) made this pull request unmergeable. Please resolve the merge conflicts.

@tomaka
Copy link
Contributor

tomaka commented Nov 26, 2015

Isn't Self known to be very buggy?
Github doesn't allow case-sensitive searches so it's a bit hard to figure out, but as far as I know there are a lot of bugs reported about this keyword.

@Gankra
Copy link
Contributor

Gankra commented Nov 26, 2015

@tomaka I use Self basically everywhere I can, and haven't ever had problems. I've only seen a bug in an unused-type lint, but the example was degenerate.

@steveklabnik
Copy link
Member

This PR has merge conflicts, can we get a rebase?

@Gankra
Copy link
Contributor

Gankra commented Jan 6, 2016

Hey @crossroads1112, sorry for the delay!

We're happy to land this if you revert the two public methods on LinkedList (split_off and append).

@Gankra
Copy link
Contributor

Gankra commented Jan 6, 2016

@tomaka I'm not familiar with any bugs? Many of us use it all the time. Perhaps associated item stuff..? (which is buggy)

@alexcrichton alexcrichton removed the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jan 13, 2016
@cmlsharp
Copy link
Author

Done

@Gankra
Copy link
Contributor

Gankra commented Jan 14, 2016

@crossroads1112 hey thanks! It seems there's some merge conflicts. Can you resolve them and squash all the commits?

@cmlsharp
Copy link
Author

Closing PR as it is replaced by this one

@cmlsharp cmlsharp closed this Jan 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants