Lived Experiences: Strange match ergonomics

[withoutboats]

Could you go into more detail about what this means? Specifically, I don’t understand the meaning of “implicit promotion”.

When you write:

let foo = &bar();

We “promote” the lifetime of the return of bar() implicitly to be longer than the expression it is in. A more restrictive / “explicit” system would require you to write:

let bar = bar();
let foo = &bar;

Hence kornel’s example would have errored unless they wrote:

let foobar = self.foobar();
let (foo, bar) = &foobar;

Which I think would have made the bug less likely, and would have also applied to the case I showed where one returns a single slice instead of a tuple of slices that is destructured.

However, I think the benefits of this promotion feature outweigh the bugs it could introduce (especially since they are the kinds of bugs that are caught, the error message is just a bit confusing).

[aidanhs]

As a variant on this, I encountered the following a few weeks ago:

pub fn new([...], config_custom_toolchains: Vec<config::CustomToolchain>) -> Self {
    [...]
    for ct in config_custom_toolchains.into_iter() {
        [...]
        let CustomToolchain { compiler_executable, archive } = ct;

        // use compiler_executable and archive

Altering the Vec in the code above to be a slice causes problems much further down in the usage of compiler_executable and archive because the types become incorrect.

This was quite confusing to me, likely because I’ve spent so long without match ergonomics that I’ve built up a particular mental model. Specifically, I see any form of let Struct { ... } = s as a checkpoint for my ‘type reasoning’ - scanning it instantly lets me know the exact types coming out of the expression (i.e. a kind of type annotation). With match ergonomics this is no longer the case and so I must either write something like let Struct { ... }: Struct = s, keep all the borrow state in my head or accept the loss of the checkpoint (so errors end up further away when I compile). I’ll be interested to see how I adapt longer term (this is my first real encounter in the wild).

I would’ve spent longer on this if I hadn’t already been aware of match ergonomics (as it’s such a sharp departure from previous behavior). It made me wonder if there are good ways to flag “the compiler made a type decision here that affects your later errors” - it’s probably not an issue for new users, but I expect initial confusion among Rust-using coworkers who (like me) need to re-examine how they reason about some bits of Rust code but (unlike me) have no idea about the match ergonomics feature.

[H2CO3]

Specifically, I see any form of let Struct { ... } = s as a checkpoint for my ‘type reasoning’ - scanning it instantly lets me know the exact types coming out of the expression

That is the exact problem, thanks for pointing it out and phrasing it so well. The binding modes changing semantics (value -> reference) without a change in syntax (nothing -> ref) are doing exactly what is the anti-thesis of good language and API design: “things that look similar should be similar, and things that look different should be different”. With the introduction of default binding modes, two bindings that look identical can radically differ in their behavior (owning vs borrowing), while two bindings that differ in the existence of the ref qualifier can behave identically (both borrowing).

This in turns breaks local reasoning (which I’m kind of puzzled why the lang team thinks is a good thing, given that the engineering of compilers is perhaps the most prevalent profession where the ability to perform local reasoning on code is paramount), which means exactly what you just complained about: you have to keep a much bigger chunk of state in your head in order to track types correctly. In other words, it makes correct reasoning harder, not easier. The only thing it makes easier is have some code compile (which would otherwise be trivial to adjust to compile anyway), but that’s arguably a feat in itself.

[CAD97]

I’ll bring this up again:

I personally expect this kind of behavior in the match expression, as it’s more often opening up a structure temporarily, and then whatever &ref are required are noise.

In a let statement, “match ergonomics” applying continues to surprise me every once in a while, as it’s primarily used to tear apart structures.

The feature was billed as “match ergonomics”. It applying to let patterns is somewhat surprising.

I still don’t know long-term whether having both patterns behave the same way is better, or if making let stricter would have been better. if let is another tricky case since what I want is pretty much 50/50.

[aidanhs]

This in turns breaks local reasoning (which I’m kind of puzzled why the lang team thinks is a good thing, given that the engineering of compilers is perhaps the most prevalent profession where the ability to perform local reasoning on code is paramount), which means exactly what you just complained about: you have to keep a much bigger chunk of state in your head in order to track types correctly.

I will say that my post is intended as an observation rather than a complaint - I wanted to express the concern for existing users and I’m genuinely interested in how I adapt longer term.

I don’t think local reasoning is uniformly better (see Java variable annotations). It is possible that patterns were the ‘just right’ on top of function annotations to naturally give Rust the perfect reasoning scope when writing code, but that would be quite a coincidence. Idiomatic Rust code evolves over time, so I’m content to wait and see how it shakes out.

The only thing it makes easier is have some code compile (which would otherwise be trivial to adjust to compile anyway)

I have over 200 annotations in this file (16 in the 33 highlighted lines, and not even considering my ‘match ergonomics’ macro mast! to auto insert box patterns) - they’re a mixture of mind-numbing manual labour and more tricky ones requiring careful consideration (most of which could be automatically inserted to avoid a match **x { X(ref mut y) => [...] dance). I wouldn’t trivialise how much match ergonomics could help.

[illustrious-you]

The feature was billed as “match ergonomics”. It applying to let patterns is somewhat surprising.

I’d like to highlight that confusion around let applies to all the examples cited so far. I’d be interested to know whether this is due to the discussion centering around individual patterns, or whether it’s common to think of let as a more strict language construct.

Personally, I share @CAD97’s opinion–I think of destructuring let as an explicit construct, and match as its more powerful (and implicit) cousin. My “inner type checker” wants if let to work the same way, for consistency, but due to its suspension between let and match, I fully expect neither approach to be a perfect fit.

Spitballing how I’d bridge the gap, I’d probably want something like a warn-level lint saying the idiom for let is explicit, and have the lint output the compiler-inferred ergonomics. For if let, I might introduce a “hint” or “info” lint that highlights ergonomics apply without “taking sides”. In terms of RLS support, a refactoring would be presented that switches between ergonomic modes. The warn lint would present the refactoring as a one-way code fix, while the “hint” lint would be bidirectional.

[kornel]

let Struct { ... } = s as a checkpoint for my ‘type reasoning’

I think that’s the essence of my complaint, too.

I think of let Struct {…} = s and let s: Struct = s as equivalent, so the mismatch between type annotation and destructuring is the uncanny valley.

[H2CO3]

to avoid a match **x { X(ref mut y) => [...] dance). I wouldn’t trivialise how much match ergonomics could help.

My point was that however helpful it might be, it does more harm than good. However, I still stand by the point that all this confusion isn’t worth it for the sake of avoiding a deref and a ref – I’m just not bothered of having to dereference a pointer and explicitly specify a ref binding. It’s just not an issue for me, and apparently, for many of us.

[rpjohnst]

That is the exact problem, thanks for pointing it out and phrasing it so well. The binding modes changing semantics (value -> reference) without a change in syntax (nothing -> ref ) are doing exactly what is the anti-thesis of good language and API design: “things that look similar should be similar, and things that look different should be different”. With the introduction of default binding modes, two bindings that look identical can radically differ in their behavior (owning vs borrowing), while two bindings that differ in the existence of the ref qualifier can behave identically (both borrowing).

This has been “broken” since before 1.0. let x = y; already “radically differs” in owning vs borrowing based on whether y is a reference. All match ergonomics does is allow this sort of thing to pass through patterns, by eliding part of the structure of types (the part built out of references).

Your jab about “local reasoning” in compilers is also incredibly disingenuous. None of the local reasoning a compiler does is at all thwarted by match ergonomics.

[H2CO3]

Your jab about “local reasoning” in compilers is also incredibly disingenuous. None of the local reasoning a compiler does is at all thwarted by match ergonomics.

No, it was an analogy. Match “ergonomics” breaks humans’ local reasoning (obviously if it broke the compiler’s, then it would have more immediately-noticeable and lower-level effects such as missed optimizations, failing to compile, or even unsoundness).

[rpjohnst]

That’s irrelevant to my point- your repeated scare quotes around “ergonomics,” and your insistence that the compiler team did something impossible to understand, are not helpful.

Match ergonomics happened, they’re helpful to some. We can discuss drawbacks and mitigations without your antagonism.

[kornel]

To be clear, I think ergonomics in match and if let is fantastic.

It has saved me a lot of hassle, tons of ugly &Enum syntax, and de-facto eliminated ref, which I think is a wart in the language (every novice had to ask about difference between ref and &).

I’m here with intention of improving just a certain case where I don’t find it valuable .

[H2CO3]

That’s irrelevant to my point

It isn’t, since you were putting words in my mouth. Again, I never asserted that the default binding modes broke the compiler, and so your claim that I did is false.

Match ergonomics happened, they’re helpful to some.

The fact that they happened doesn’t in itself imply that they are universally helpful. Yes, they are helpful to some. Yes, I think they are also harmful. That’s not an oxymoron – there are many features in many languages that seemed to be a good idea because they made some things easier, but turned out to have unexpected consequences or be dangerous in other situations. Array-to-pointer decay in C, automatic semicolon insertion in JavaScript, all these features were intended as helpful shortcuts, but in the end they happen to have more negative effects than the marginal helpfulness would be worth it. My claim is that pattern match ergonomics is one such feature too. Not because of the compiler, but because of human users of the language.

without your antagonism.

Your personal insults aren’t helpful either, and I’m not willing to continue/litigate this further.

[withoutboats]

Your personal insults aren’t helpful either, and I’m not willing to continue/litigate this further.

On this and other issues you have behaved with considerable antagonism, @rpjohnst telling you how it is impacting the conversation is not an insult. Every time you have been informed that your antagonism is disruptive, you have responded in this exact manner. I believe you have genuine intentions to have a positive impact on Rust: the tenor you have adopted on this forum is extremely counterproductive to that end.

[withoutboats]

We definitely didn’t consider deeply the possibility that there was a difference in experience and desire between refutable and irrefutable patterns. I think when you are sufficiently intimate with how Rust works, the answer seems obvious: “this is totally orthogonal to refutability, it would be inconsistent and confusing if it didn’t apply across the board.” But I believe that for many users, destructuring with let and with match felt significantly different from one another, and whereas this change might’ve removed noise in one case, it might be surprising in the other.

On the other hand, like I think several people have commented, this is probably impacted a lot by having learned Rust without the feature: its possible that people learning Rust now will not find its application in let surprising at all. If newer users continue to have trouble with this, though, I think it would be worth revisiting whether or not applying match ergonomics to irrefutable patterns was a mistake in the next edition after 2018.

[mbrubeck]

17 posts were split to a new topic: Linting and match ergonomics

[scottmcm]

This has been “broken” since before 1.0. let x = y; already “radically differs” in owning vs borrowing based on whether y is a reference. All match ergonomics does is allow this sort of thing to pass through patterns, by eliding part of the structure of types (the part built out of references).

I think this is an interesting argument for something like Random Musings: types in patterns : the way this is dealt with in that case is by adding a type (x in let x: u32 = y; is definitely not a borrow), so the same would work inside a pattern (x in let Struct { x: i32 } = y; is definitely not a borrow).

[Ixrec]

A lint specifically against “match ergonomics” does feel like dissensus to me, but there’s an implication in phaylon’s last few posts that this is an arbitrary distinction, and I think he’s on to something there.

I believe there are two concrete reasons why I personally get that impression from a match ergonomics lint but not from e.g. an unsafe code lint:

1. Timing and context. As @withoutboats put it: “The negative reaction I’ve seen on this and other issues in clippy has been to … just disable whole features through clippy right after they’re stabilized.” Phaylon’s last few posts here are the first time I’ve seen anyone suggest they only want to disable match ergonomics in some of their code, rather than completely disable the feature.

2. “match ergonomics” is not really an independent feature. It’s a change to type inference. Like “non-lexical lifetimes”, once it’s stabilised we’ll probably stop talking as if it’s a separate feature in need of a separate name. After all, that’s why we’re content to continue using a name that describes the motivation for the feature rather than the feature itself; it can’t mislead future novices if it’s going to disappear anyway.

#2 in particular makes me want to ask: @phaylon how would you feel about linting against all type inference in your most sensitive code?

[nielsle]

I am quite happy about the match ergonomics. You can often debug the matches by adding an extra type constraint

struct Z;
fn foo(w: Z) { }

pub fn main() {
    let v = &Some(Some(Some(Some(Z))));
    let Some(w) = v;
    let Some(x): Option<_> = w;
    let Some(y) = x;
    let Some(z) = y;
    foo(z);
}

Error message

9 |     let Some(x): Option<_> = w;
  |                              ^
  |                              |
  |                              expected enum `std::option::Option`, found reference
  |                              help: try using a variant of the expected type: `Some(w)`
  |
  = note: expected type `std::option::Option<_>`
             found type `&std::option::Option<std::option::Option<std::option::Option<Z>>>`

But this approach becomes clumsy if w has the type MySurprisinglyLongEnumName. Is there a shorter way to require that w is not a reference?

Ideally rustc should follow the trail of matches and warn the user that x is a reference because v is a reference, but that may not be easy.

[illustrious-you]

Hey, everyone, the conversation has gone way off base, and in the process turned from heated to accusing. Let’s all agree to take a break and cool off.

This is a thread about discussing strange effects related to match ergonomics. If you’d like to continue listing those, please continue. If you have other topics, please start a new thread.

(ProTip: You can branch off of any post by clicking the age indicator in the top-right and selecting “+ new topic”.)