0000-template.md: Encourage discussion of maintanence

[joshtriplett]

Add some points to encourage RFCs to discuss how a proposal impacts the
ease of reading, understanding, and maintaining Rust code, not just the
ease of writing it.

Inspired by many recent discussions on proposed language features.

cc @rust-lang/lang

[mgeisler]

Thanks, I think this is a great addition.

[Centril]

This does not constitute a change in policy right, just a reminder to authors?

The changes in the text look super great to me 💯.

[joshtriplett]

@Centril I don't think this is a change to policy, no, just some encouragement to cover this point in RFC text.

[WiSaGaN]

I think one of related points is to invite more industrial users to voice their opinion and concern. They are the main proponents for language adoption, and they have more experience in using the language in production.

[WiSaGaN]

We may also consider IDE assistence (in RLS, e.g.) in improving ergonomics if the change in language could not improve lanugage consistency, or reducing language complexity. We do own RLS, so IDEs should also constitute as a component when we view "Rust" as a product.

[Centril]

IDE assistance plays a part for sure, particularly to improve writing flow, but remember that not everyone uses an IDE. In my view it should be possible to log into a headless server with only nano, or a bare bones vim installation, and modify some small piece of Rust code and recompile for example.

Therefore, I think that readability and maintenance of code should not be much based on IDEs. For example, in my view, duplicating code with an IDE as a substitute for parametric polymorphism and traits in the past would not have been a good trade-off, and going forward, similar expressiveness-boosts in the type system should not be substituted with IDEs.

[WiSaGaN]

I think you misunderstood my point. The readability and maintenance of the code relies on stability of the language. If something that can be done outside of the language, we probably should consider do it outside of the language because it reduces the learning burden of the user, and alleviate the gradual language bloat we see in also most long-lived major languages.

I use Vim, and I don't think using Vim prevents anything I do in Rust, even that we already have a lot of ergonomic assistance in IDEs from VSCode, IntelliJ Rust, etc.

What I do mean is that for example: if some user wants to avoid typing Ok(()) at the end of a function that returns a Result<(), T>, they may consider to use an IDE that auto completes for them, instead of creating different ways of returning in a function in the language.

[Centril]

No, I understood that point. Auto-completion can play a part, but if auto-completion adds large amounts of boilerplate from repetitive tasks, then it harms readability (for the person who is looking at a git PR for example...), maintenance and suggests that the language is not up to the task, or that the language hasn't given library authors the ability to automate (generate code) inside the language.

Using Vim as your every day editor is very different from logging into a headless server and using a nano which has zero syntax highlighting and no plugins for Rust. It is just a text editor, it has no IDE facilities.

I'm going to avoid the discussion on Ok-wrapping here.

[leodasvacas]

not everyone uses an IDE

Not everyone likes using macros, not everyone likes/can pull in dependencies, even std is not used by everyone. Similar to other out-of-language solutions, IDEs do not reach everybody but might reach a considerable share of Rust users. In the discussion for the import path reform, IDE support for writing imports was a relevant argument.

[burdges]

Just a fun quotes from Yaron Minsky's Effective ML talk:
"Whenever there is a difference of opinion between [the writer of code and the reader of code], the readers are always right and the writers are always wrong." -

I'm not criticizing recent ergonomics features here, like default binding modes might make auditing the logic's correctness easier. I just like the sentiment overall. :) In fact, another couple fun quotes from his Caml Trading talk:
"You basically cannot pay people enough to code review dull [boiler plate] code. .. We've tried."
"Any [mental tools] that let you offload [the informal proofs involved in reading code] is a huge win"

[nikomatsakis]

I'm a bit concerned that the templates are becoming a kind of laundry list. I'm a bit concerned because complex templates are a bit of a barrier to entry and often don't apply to all teams (e.g., does this apply to a "policy RFC"?).

Furthermore, people can simply delete these points, and then it's as if they never existed — when really what we want is to ensure that the discussion takes these points into account.

I have an alternate proposal. Instead of putting this text in the template, where it can be deleted or overwhelming, maybe we should make a "review-guidelines" directory on the repository with "per team" advice. So e.g. the lang team could include this (and other) considerations. We can then add advice encouraging reviewers -- both team members and non-team members alike -- review the RFC with respect to these criteria (in addition to their general thoughts).

[joshtriplett]

@nikomatsakis I can absolutely agree that an excessively busy template could do as much harm as good. I would certainly be happy to edit the templates in more detail, and perhaps attempt to streamline them somewhat in ways that reflect how people tend to describe proposed changes in practice.

However, I do think part of this change ("Does the proposed change make Rust code easier or harder to read, understand, and maintain?") applies to any kind of change, library and language alike. The "If this is a language change" bit is perhaps more awkward. I think I could find a way to make it fit better, though.

Does that seem plausible?