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

Allow mut on self/~self like other args. #9989

Merged
merged 4 commits into from
Oct 23, 2013
Merged

Conversation

luqmana
Copy link
Member

@luqmana luqmana commented Oct 21, 2013

No description provided.

@huonw
Copy link
Member

huonw commented Oct 21, 2013

Does the manual/tutorial need to be updated for this?

@jdm
Copy link
Contributor

jdm commented Oct 21, 2013

I was just wishing for this a few days ago. Excellent. 🌵

@bstrie
Copy link
Contributor

bstrie commented Oct 21, 2013

I'd like an explanation on why mut ~self is desirable. Is there an issue open on this topic?

@luqmana
Copy link
Member Author

luqmana commented Oct 21, 2013

@bstrie There are quite a few places where just immediately do something like let mut this = self in the body of a method taking ~self. This just saves you a bit of typing and treats self/~self like other arguments in which you can already do this.

@huonw Yea, I guess I'll update this later to include those changes.

@bstrie
Copy link
Contributor

bstrie commented Oct 21, 2013

Ok, I get the idea now.

However, I'd still like one of the primary devs to weigh in on this before anyone approves it.

@alexcrichton
Copy link
Member

This is great! I've certainly been wonting for this for awhile.

@bstrie, I believe that there's nothing unsound about this because the function has ownership of self or ~self, so it gets to decide the mutability of the contents. @luqmana is right in that there are lots of locations you'll find let mut this = self to work around not being able to bind self as mutable in the function declaration.

I'd also be interested in a test or two with a mutable self in a default trait method. I know that there were bugs in the past for that, and I doubt that there's actually any bugs here, but better safe than sorry!

@brson
Copy link
Contributor

brson commented Oct 21, 2013

I don't recall any previous discussion of this. Let's talk about it in the meeting tomorrow.

@luqmana
Copy link
Member Author

luqmana commented Oct 22, 2013

@brson Cool, in that case can #9792 also be clarified as either something we want or not since it is marked B-RFC and I have some work towards it.

@@ -0,0 +1,30 @@
// Copyright 2012 The Rust Project Developers. See the COPYRIGHT
Copy link
Contributor

Choose a reason for hiding this comment

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

It's 2013 :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Right you are :P

@brson
Copy link
Contributor

brson commented Oct 22, 2013

Consensus is that we should do this.

@brson
Copy link
Contributor

brson commented Oct 22, 2013

@luqmana Can you put something in the manual about this?

@bors bors closed this Oct 23, 2013
@bors bors merged commit b2b2095 into rust-lang:master Oct 23, 2013
@luqmana luqmana deleted the mut-everywhere branch March 2, 2014 08:32
flip1995 pushed a commit to flip1995/rust that referenced this pull request Dec 1, 2022
…ip1995

Move `unnecessary_unsafety_doc` to `pedantic`

This lint was added in rust-lang#9822. I like the idea, but also agree with rust-lang#9986 as well. I think it should at least not be warn-by-default. This is one of these cases, where I'd like a group between pedantic and restriction. But I believe that users using `#![warn(clippy::pedantic)]` will know how to enable the lint if they disagree with it.

---

Since the lint is new:

changelog: none

r? `@flip1995` since I'd suggest back porting this, the original PR was merged 16 days ago.

Closes: rust-lang#9986 (While it doesn't address everything, I believe that this is the best compromise)
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.

8 participants