The various planned breaking changes to the language in the name of ergonomics are damn scary.
-
-
-
Replying to @brendanzab @graydon_pub and
Module changes, `mut` being implicit in some circumstances, argument-bound lifetimes, the `T throws E` proposal (not planned yet though, fortunately), etc…
1 reply 0 retweets 0 likes -
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
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”.
-
-
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 - 4 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.