-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Explicit move binding mode #3410
base: master
Are you sure you want to change the base?
Explicit move binding mode #3410
Conversation
…age=none and turn one into an error
For context, there’s a URLO discussion where the motivation for writing this RFC probably emerged. I don’t know yet what I’d like to contribute from that thread to this discussion… but to paraphrase my own take on binding modes in the context of match ergonomics from that thread: I believe it might be worth a change to lint (or eventually even error, or error-by-default-lint) in general against any
In case that isn’t clear from the above, I believe that complicated settings should require the user to fall back to patterns that properly match the type, i.e. to no longer use match ergonomics. This could also be aided by help messages in diagnostics. I don’t want to say that there’s no truth to the argument that “requiring the user to add lots of
there’d be some consistency to that; and the way to write |
You are correct that this RFC originates from that discussion. I originally included a link to it but was advised against it by a member of the Discord community. I will update the alternatives section to elaborate further on your alternative. |
As an alternative: Rust use let (x, const y, mut z) = &mut xyz;
// The type of `x` is `&mut i32` and
// the type of `y` is `&i32` and
// the type of `z` is `i32` (and the binding is mutable)
let (x, const y) = &xy;
// The type of `x` is `&i32` and
// the type of `y` is `i32` P.S. It is legal already to write let (x, mut y) = &xy;
let (x, ref y, mut z) = &mut xyz; |
For context, an alternative to ref/move
is mut/const
or both |
…dy kind of possible
a1eba65
to
17522df
Compare
There is no need for anything like this. It's just piling even more special cases on top of the already-confusing match "ergonomics". Just make sure that the pattern's type matches that of the value, it's as simple as that. |
This isn’t a special case. It’s simply filling an obvious gap in the existing match ergonomics. If you don’t like match ergonomics, that’s fine, but it’s here and people use it. Even if the “better” approach is to just not use match ergonomics, having a half-baked feature in the language is worse than having one that’s on par with the alternative in what it can do. Also, have you read the alternatives section of the RFC? It contains an alternative implementation of match ergonomics suggested by @steffahn that may be more to your liking. |
I’m not suggesting putting |
I have talked to other community members on the community Discord Server about this and there seems to be no clear answer. Perhaps no-one came up with this during the match ergonomics RFC period. However there may be subtle problems in the implementation which is why I didn’t feel confident to suggest this change. I feel this proposal is much more conservative as it suggest exposing functionality that is already present ( |
I was talking about unnecessary |
Well, the point of match ergonomics is to avoid writing Please don't spread your replies over many messages, it makes hard to keep track of discussion. |
Regardless of choice of keyword (let's go with Of course, assuming this outcome is realistic, it would be a bad outcome, because we already have true dereferencing patterns If we follow argument that
Regarding edition boundaries... the kind of syntax that might change in meaning over an edition is Without/before an edition boundary, we can simply lint against all this syntax that would change in meaning (because it would then become a corner case incompatible with the new concept of how match ergonomics operate, only kept for backwards compatibility). Even after an edition we could still consider just having it error instead of introducing the new consistent meaning of |
@steffahn |
@VitWW |
May I leave my two cents? I think Rust should go in the opposite direction. Rely solely on match ergonomics and deprecate the In my experience, I manage to never use the |
That would be massively harmful, primarily in |
@H2CO3 Can you elaborate on that further? With this RFC match ergonomics are almost identical in power to "Rust 2015 matching", meaning that Rust 2015 matching can almost be deprecated. I don't know how any of this has anything to do with unsafe or types that don't match. |
First, I don't care about "power"; it's not what I am talking about. I am talking about situations where whether or not a type is a reference is important, and you want to be explicit about types rather than letting the compiler second-guess you. In
There's no need to deprecate anything. Just because there's a convenience feature, it doesn't mean that the option of being explicit should be taken away from people. This is exactly the kind of slippery slope I and many others had been worrying and warning about when match ergonomics was introduced. |
@H2CO3 you example show how match ergonomics might be dangerous in unsafe context. OK. How
I explained the reasons: If you are arguing that match ergonomics need to be deprecated instead, this is a different topic. |
I was not; refrain from putting words into my mouth.
Being explicit about the types would make the code safe. That may or may not involve |
I'm sorry Árpád, I didn't mean to. Just trying to understand.
I generally agree about type safety: that's what we love Rust for. I didn't get how |
@H2CO3 |
I think your example also shows how I don’t see a strong argument against |
@stepancheg I wouldn't have fought painfully for years (and I mean literally years) to get a clippy lint accepted to enforce explicit binding modes if it were useless. I wouldn't have put myself through all of that pain, the attacks, and the insults if I wouldn't get a value out of it,. So I would appreciate it if everyone started with the assumption that if they don't see a use for something, that doesn't mean nobody else does. And that you don't have to be convinced of it's usefulness for it to be of great value to others. It has explicit, mechanical functions that no other parts of the language provide:
So after years of discussions, roadblocks, fighting about this and all other things. I'm sorry I'm not convinced we need to remove it because not everyone uses it. There are still no suitable replacements for the things it does. If people want to "fix" match ergonomics, I'd propose not going for just 90% of cases and have the rest not work, and not going for a hard-to-one-side total removal that leaves parts of the community in the dust. Instead go for a holistic approach where the explicit underlying mechanics give explicit control, and have a high level approach for those that don't care and where it doesn't matter much. |
@phaylon I should choose my words more carefully. I'll rephrase. I read code by various people, including open source project, and I see that Even if some people find Basically, simple language is better if it is equally expressible.
Did he? In his examples,
I didn't get that. I'm only talking about |
@phaylon Just for clarity: this RFC do not propose anything to remove. |
You keep coming back to whether If you want, you can trivially rewrite my earlier example to include |
You can do this using match ergonomics, as they currently exist, too—you just have to explicitly specify |
But it isn't equally expressible. It can't express the restrictions and it can't express multi-mode destructuring. The restrictions are of the same value as all other restrictions in Rust. See:
If someone removes The same applies to match ergonomics vs. explicit binding modes. The multi-mode destructuring capabilities come in when you do things like
where you get exhaustiveness checking, explicit mode checking, and IDE highlighting of mutable bindings at the top of a function giving you detailed context about the things the function manipulates. This is very handy when your type dispatches to some free functions that manipulate the individual components. And that can happen in all more complex scenarios, like state machines:
is a lot more expressive and clean to me than
The former gives a lot more context to what's going on, applies restrictions (why even give the ability to the code block to mess with the bound And with all language-level restrictions, since they are at the language level instead of just convention, you can count on them to kick in in
I am aware, apologies for not mentioning it. As you can tell I'm all for more explicitness and control :) It was more intended as a defense of the general idea of control in general, instead of a rebuke of the advancement. Edit: I actually just checked and it seems VSCode doesn't even highlight the bindings in all cases. It must be my brain inserting that when I see the |
Well, you have replied to my comment about proposal to remove
You said, quoting:
So I'm asking for explanation/illustration, how exactly removal of
Equally incorrect code can be easily written with |
Anyway, now that I've given my defense of explicit binding modes, I'll go back to lurking. I hope it will help demonstrate the value it has to some of us, and how expanding the ways to fully qualify patterns as the proposal attempts are things worthy of consideration. And again: Apologies to OP for it being more expansive than I had anticipated. |
While Proposal #3627 (Match ergonomics 2024) is accepted, is this proposal still valid? |
This RFC suggests using the
move
keyword to explicitly specify the moving binding mode to override match ergonomicsRendered