Consensus check: let-chains and is are not mutually exclusive

[joshtriplett]

In a recent lang design planning meeting, we discussed whether we considered let-chains (if let pat = expr && let pat2 = expr2) and is (if expr is pat && expr2 is pat2) mutually exclusive, such that accepting one made us disinclined to consider the other.

The consensus from the meeting was that we consider these features both potentially valuable, and that accepting one does not preclude us from considering the other on the sole basis of having more than one way to do something.

Filing this issue to record and confirm that consensus.

To be clear, this consensus would not mean* that we are committing to accept is, just that we don't think the two features are inherently mutually exclusive.

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

@rfcbot reviewed

I don't know where we'll land on is, but we need to follow through on let chains. It's OK if we have two ways to do things sometimes. Often one is better in one place and another in another place. And there are path dependencies that reasonably lead to this. So I would not raise the existence of if-let chains as an argument against is.

[tmandry]

I'm fine with saying that we will still consider is, even though let-chains exist. It's okay in principle if there is more than one way to express something. We should of course still consider every feature in the context of the language as it exists and make sure it still carries its weight.

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

I'm happy to say we're not going to immediately dismiss a proposal for is just based on the existence of let chains. It's not dispositive on its own.

That said, it absolutely needs to be considered. "You can do similar things with let chains" is absolutely something that I would expect to be in the Disadvantages section of a hypothetical RFC for is, and I'd probably block an is RFC that didn't discuss that conflict.

And I could absolutely imagine a version of is that means I stop using if let entirely, let alone let chains. So in some ways I could see them becoming defacto mutually exclusive.

But under the interpretation of my first paragraph here, and knowing it's not a one-way door anyway,
@rfcbot reviewed

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.