GitHub PullRequestReviewCommentEvent at 2014-05-18 19:03:24
Repository: rfcs
Actor: thestinger
Payload: {"comment":{"url":"https://api.github.com/repos/rust-lang/rfcs/pulls/comments/12775648","id":12775648,"diff_hunk":"@@ -0,0 +1,315 @@\n+- Start Date: 2014-05-16\n+- RFC PR #: (leave this empty)\n+- Rust Issue #: (leave this empty)\n+\n+\n+# Summary\n+\n+Introducing an orthogonal handling of mutability and aliasing, which will hopefully make code clearer to read and increase the scope of what can be written without dropping to unsafe code.\n+\n+\n+# Motivation\n+\n+The current system of handling mutability is confusing and requires unsafe code and compiler hacks. It is confusing because types like `Cell` can be mutated through `&T` references as they are internally mutable (an invisible property) and requires compiler hacks in the way closures are modelled.\n+\n+*Note: a concurrent RFC for [unboxed closures](https://github.com/rust-lang/rfcs/pull/77/) might solve the closure issue; it does not address the confusion issue though, nor the necessity to drop to unsafe code in order to mutate aliased objects.*\n+\n+The confusion is not helped by the compiler diagnostics:\n+\n+```rust\n+use std::cell::Cell;\n+\n+fn main() {\n+    let c = Cell::new(4);   // note: prior assignment occurs here\n+    c.set(3);\n+    c = Cell::new(5);       // error: re-assignment of immutable variable `c`\n+}\n+```\n+\n+So, it's okay to mutate `c` via `set`, but not to assign to `c` because it is *immutable*...","path":"active/0000-extending-safe-mutability.md","position":29,"original_position":29,"commit_id":"b3f8f0b3a310aca5e0a083c62aa560b781c70c90","original_commit_id":"b3f8f0b3a310aca5e0a083c62aa560b781c70c90","user":{"login":"thestinger","id":1505226,"avatar_url":"https://avatars.githubusercontent.com/u/1505226?","gravatar_id":"0d3dda58e2ef5ba8dc98f5e46997262c","url":"https://api.github.com/users/thestinger","html_url":"https://github.com/thestinger","followers_url":"https://api.github.com/users/thestinger/followers","following_url":"https://api.github.com/users/thestinger/following{/other_user}","gists_url":"https://api.github.com/users/thestinger/gists{/gist_id}","starred_url":"https://api.github.com/users/thestinger/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thestinger/subscriptions","organizations_url":"https://api.github.com/users/thestinger/orgs","repos_url":"https://api.github.com/users/thestinger/repos","events_url":"https://api.github.com/users/thestinger/events{/privacy}","received_events_url":"https://api.github.com/users/thestinger/received_events","type":"User","site_admin":false},"body":"That's right, a mutable variable means you *can assign to it*. This is how mutable and immutable variables work in most languages, and yet no one claims `val` vs. `var` in Scala in confusing. The feigned confusion about this weakens the argument against the current system.","created_at":"2014-05-18T19:03:24Z","updated_at":"2014-05-18T19:03:24Z","html_url":"https://github.com/rust-lang/rfcs/pull/78#discussion_r12775648","pull_request_url":"https://api.github.com/repos/rust-lang/rfcs/pulls/78","_links":{"self":{"href":"https://api.github.com/repos/rust-lang/rfcs/pulls/comments/12775648"},"html":{"href":"https://github.com/rust-lang/rfcs/pull/78#discussion_r12775648"},"pull_request":{"href":"https://api.github.com/repos/rust-lang/rfcs/pulls/78"}}}}