Module changes, `mut` being implicit in some circumstances, argument-bound lifetimes, the `T throws E` proposal (not planned yet though, fortunately), etc…
-
-
Replying to @nokusu @brendanzab and
Most of these are simplifications though, honestly.
1 reply 0 retweets 1 like -
Replying to @pcwalton @brendanzab and
I strongly disagree to that, most of those changes are optimising code for writing and vague notions of "happiness" or whatever, and they will ultimately hinder code reviewing because you'll need to keep more stuff in mind to follow the code. Cf.https://github.com/rust-lang/rust/issues/42640#issuecomment-368161767 …
1 reply 0 retweets 0 likes -
Replying to @nokusu @brendanzab and
I don’t share the concern. I remember lots of similar concerns around things that were totally uncontroversial now; e.g. “none.” vs. “None”
1 reply 0 retweets 0 likes -
Or capture clauses. This is actually a very similar situation to capture clauses, and it ended up not mattering at all.
1 reply 0 retweets 0 likes -
Replying to @pcwalton @brendanzab and
That's because we have `move` for closures that capture. That's completely unrelated to reading code and not even knowing if a value was moved or not. I do know from my own experience that I rely on all those visual cues a lot. "none" vs "None" is entirely offtopic.
2 replies 0 retweets 0 likes -
Replying to @nokusu @brendanzab and
Or Moves-Based-On-Type. That was controversial too! Turned out to not matter.
1 reply 0 retweets 1 like -
Replying to @pcwalton @brendanzab and
Still offtopic. Moves based on type don't introduce mutability out of nowhere, nor does it radically change the meaning of an expression a hundred lines later like `T throws E` for example.
1 reply 0 retweets 0 likes -
Replying to @nokusu @brendanzab and
It’s not off topic! Stop it. MBOT doesn’t, but closures *do* introduce mutability “out of nowhere”. I don’t know about “T throws E”.
1 reply 0 retweets 1 like -
Replying to @pcwalton @brendanzab and
Show me code where a value outside a closure is not mutable but is mutable inside of it and I'll concede to that. But my point still stands: it increases the areas where I need to look out for mutability. As for `T throws E`, it's not a RFC yet:https://internals.rust-lang.org/t/pre-rfc-catching-functions/6505 …
1 reply 0 retweets 0 likes
The analogy with closures is that they infer “&” vs. “&mut” borrows of upvars based on usage. That introduces invisible mutability.
-
-
Replying to @pcwalton @brendanzab and
But that's only because the value was already originally a `&mut`. I don't think this is similar to pattern matching a `&mut T` with bindings without an explicit `ref mut` mode and being able to call mutable methods.
2 replies 0 retweets 0 likes -
let mut x = Foo::new(); || {http://x.bar += 1} vs let mut x = Foo::new(); match x.foobar { Bar(ref mut x) => x += 1 }
1 reply 0 retweets 1 like - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.