Linting and match ergonomics

language design
9

In some cases it would certainly be nice, but I'd prefer fine grained options. For example: I'll give explicit types to parts I consider important in unsafe code. If they all get type information, nothing stands out anymore. If there were a "be explicit about all bindings that are involved in unsafe code" lint I might activate that. But my main concern are references and lfietimes. That's why I love the '_ change for example.

The thing is: With things like match ergonomics, in-band lifetimes, impl Trait in argument position and all the other ergonomic local-information hiding features I already dissent by not using them. The lint has no influence on that. The lack of the lint only causes me pain, and will cause contributors pain.

Honestly I'm mostly hurt by the constant framing of the issue as me harming the community by people in leadership positions. That's why I'm so bitter.

Here's some current opportunities to create dialects:

  • Don't allow as conversions in your code.
  • Don't allow impl Trait in argument position.
  • Bounds go in where clauses, not in the <T> declaration.
  • Don't use ?.
  • Always use match over if let and be exhaustive.
  • Support an older version of rustc.
  • Be no_std.
  • Disallow unsafe.

But if you make these kinds of decisions you aren't villified.

At this point I'm honestly baffled. All these ergonomics changes work by hiding local information. Of course some people are going to be uncomfortable with that. And they focus on match ergonomics because that's the gravest one, since you might not even tell it's happening in a diff.

And since we're apparently now full in on calling people like me dissenters: I don't care about communicating my dissent through code. I just want the ability to enforce project standards, and not be told I'm a bad person for that.

It would be great if everyone assuming me and others are just dissenters would just try to assume good faith. Try to imagine if we could have non-ulterior motives here.

A final repeated plea to the leadership: Don't say people who don't like a feature are "dissenters". Don't accuse people of splitting and harming the community because they don't have buy-in to a feature. To me, this is even worse than people just not caring about my usecase.

And if people don't want a feature in certain or all contexts, try to understand why. I promise you we have reasons. We're not just assholes. If there are other solutions, we're happy. For example: The type description idea above for patterns would be great if coupled with a "no match ergonomics for explicit types" lint. It's one thing to disagree, or to not care, but please stop painting us as malicious.

8 Likes