RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods

@aliemjay

I noticed (while responding to this comment by @aliemjay) that there's an inconsistency in how we handle returning Self if it captures lifetimes. For both inherent methods and RPITIT, if you write -> impl Trait and then return self on an impl for a type that containing a lifetime, we give you an error:

struct Foo<'a>(&'a str);

// ERROR: hidden type for `impl Sized` captures lifetime that does not appear in bounds
impl<'a> Foo<'a> {
    fn foo(self) -> impl Sized { self }
}

trait Trait<'a> {
    fn bar(self) -> impl Sized;
}

// ERROR: hidden type for `impl Sized` captures lifetime that does not appear in bounds
impl<'a> Trait<'a> for &'a i32 {
    fn bar(self) -> impl Sized { self }
}

However, if you write -> Self on an implementation of a trait method that's written with -> impl Trait, there is no error (though this would require #[refine] with RFC 3245):

// OK?
impl<'a> Trait<'a> for &'a u32 {
    fn bar(self) -> Self { self }
}

playground

First, this inconsistency is weird from a user perspective because it seems like the capture rules say what lifetimes your hidden type is allowed to reference, and such a property can only be strengthened by an implementation (by referencing fewer, or longer-lived, lifetimes than the trait allows), never weakened. But here, the implementation specifies it a concrete type which allows it to name additional lifetimes.

If we could I we would say we should probably accept all of these examples and consider Self to be a type parameter in how we interpret RFC 1951. That said, I don't think it's possible to change today given that you can depend on the return type not referencing the lifetime.

Given that, we should probably apply the same restriction to RPITIT for the sake of consistency and not allow it to name any lifetime parameters as we assume it can today (including through Self). Though this might create other issues I'm not thinking of.

cc @compiler-errors

Remove "Self" as a "type parameter" wrt scoping rules

This is even more problematic when considering you can capture early-bound lifetimes not named by the opaque:

#![feature(async_fn_in_trait)]
#![feature(return_position_impl_trait_in_trait)]

use std::future::Future;

pub trait Trait {
    fn foo<'a: 'a>(&'a self) -> impl Future<Output = ()>;
}

pub struct S;

impl Trait for S {
    async fn foo<'s: 's>(&'s self) -> () {}
}

fn main() {}

but not late-bound ones¹:

#![feature(async_fn_in_trait)]
#![feature(return_position_impl_trait_in_trait)]
use std::future::Future;

pub trait Trait {
    fn foo<'a>(&'a self) -> impl Future<Output = ()>;
}

pub struct S;

impl Trait for S {
    async fn foo<'s>(&'s self) -> () {}
    //~^ ERROR `impl` item signature doesn't match `trait` item signature
}

fn main() {}

Which for technical reason we should never be able to capture, since we literally don't have a way of desugaring that as a GAT. ↩

Perhaps we should consider example (1.) from my previous comment to be a refinement since it references a function lifetime parameter that isn't mentioned by the opaque, and deny it.

What to do with self types is a bit more delicate, as you noted above, and I have no idea what the best choice is there.

Rollup merge of rust-lang#113182 - compiler-errors:rpit-stricter-capt…

Auto merge of rust-lang#114489 - compiler-errors:rpitit-capture-all, …

Navigation Menu

Repository navigation

RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods #112194

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods #112194

Description

Activity

compiler-errors commented on Jun 26, 2023

Footnotes

compiler-errors commented on Jun 26, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions