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 …
-
-
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 -
Replying to @nokusu @brendanzab and
The analogy with closures is that they infer “&” vs. “&mut” borrows of upvars based on usage. That introduces invisible mutability.
1 reply 0 retweets 1 like -
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
What’s wrong with that? I hate typing “ref mut” to mutate something that was already mutable in the “match” header :)
-
-
Replying to @pcwalton @brendanzab and
Because if I don't see `ref mut`, I don't expect the value to be mutated, and the mutability from the original value is not necessarily discoverable locally.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.