Elided lifetime changes in `rust_2018_idioms` lint is very noisy and results in dramatically degraded APIs for Bevy

[alice-i-cecile]

Problem

With the upcoming release of Rust 2024 edition, rust_2018_idioms will be deny by default.

We investigated what these changes will entail for Bevy in https://github.com/bevyengine/bevy/pull/15916, and the impact is quite severe. Our primary user-facing system and query APIs are littered with meaningless lifetimes.

This is a much worse experience with no upside for us, and Bevy and its entire ecosystem will have to manually allow this lint on every project.

Proposed solution

We would appreciate if the elided lifetimes lint could be split out from the rest of the rust_2018_idioms linting, which we generally liked the effect of.

Ideally this would be off by default as well, to avoid needing to teach new users to turn it off as a critical part of project setup.

[alice-i-cecile]

Here's an example of some in-production code after this lint was applied:

pub fn update_text2d_layout(
    // Text items which should be reprocessed again, generally when the font hasn't loaded yet.
    mut queue: Local<'_, HashSet<Entity>>,
    mut textures: ResMut<'_, Assets<Image>>,
    fonts: Res<'_, Assets<Font>>,
    windows: Query<'_, '_, &Window, With<PrimaryWindow>>,
    mut scale_factor_changed: EventReader<'_, '_, WindowScaleFactorChanged>,
    mut texture_atlases: ResMut<'_, Assets<TextureAtlasLayout>>,
    mut font_atlas_sets: ResMut<'_, FontAtlasSets>,
    mut text_pipeline: ResMut<'_, TextPipeline>,
    mut text_query: Query<'_, '_, (
        Entity,
        Ref<'_, TextLayout>,
        Ref<'_, TextBounds>,
        &mut TextLayoutInfo,
        &mut ComputedTextBlock,
    )>,
    mut text_reader: Text2dReader<'_, '_>,
    mut font_system: ResMut<'_, CosmicFontSystem>,
    mut swash_cache: ResMut<'_, SwashCache>,
) {

[jieyouxu]

Since this seems to have potential non-minimal ecosystem impact, nominating for T-lang discussion. @rustbot label +I-lang-nominated

[alice-i-cecile]

Turning this on by default is tracked in https://github.com/rust-lang/rust/issues/54910 and https://github.com/rust-lang/rust/issues/91639.

[epage]

I recently found that I didn't have rust_2018_idioms set to warn in my projects and did so. I found I had many elided lifetimes and I almost always found it to made the code harder to read as the signal to noise ratio went down. I was a big fan of the explicitness back when it first came out but it seems like its actually redundant in many cases.

Take a Display impl.

impl Display for PartialVersion {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        // ...
    }
}

The fact that data is being borrowed has little use for the person reading or writing this function. This might seem like a trivial case but its also a case that new users will be more likely to run into and requires introducing more concepts for them to write basic idiomatic code.

I can see more of a case for it in return values as it the fact that a borrow occurs there is much more likely to affect people.

[RalfJung]

I can see more of a case for it in return values as it the fact that a borrow occurs there is much more likely to affect people.

Yeah, I agree -- borrows that only last for the duration of the call are very non-intrusive and can often be ignored. But when lifetimes show up in the return value, they can start impacting how one has to arrange the code on the caller side.

@alice-i-cecile does Bevy have any cases of elided lifetimes in return types where you think elision is desirable, or does it only affect argument types? (I guess this may be hard to say because the lint fires so often that you don't notice the return type cases among the noise...)

[jhpratt]

For what it's worth, I've had this set to deny for years in my projects and have found it to be useful. That's not to say that I'm opposed to splitting the lint up, however.

The lint may be able to be improved to where it's actually necessary, but my assumption was that something like this was intended to become a hard error in the future, just as other edition changes are.