Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: extended_hrtbs #3261

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Conversation

tema3210
Copy link

@tema3210 tema3210 commented May 8, 2022

RFC for bounded universal quantification for lifetimes

Rendered

Internals thread

@tema3210 tema3210 changed the title Add extended_hrtbs RFC RFC: extended_hrtbs May 8, 2022
@clarfonthey
Copy link
Contributor

clarfonthey commented May 8, 2022

Could you please, somewhere in the RFC, define HRTBs as higher-rank trait bounds? I had to look that up even though I understand the for<'a> syntax.

@nrc nrc added the T-lang Relevant to the language team, which will review and decide on the RFC. label May 9, 2022
@jackh726
Copy link
Member

So, two thoughts:

First, I'd like for this to not really be needed in most cases if ever. We should be able to use some form of implied bounds here. We've had some discussion around a-mir-formality about this.

Second, I personally prefer for<'a> where <'i: 'a> I::Item<'a>: Debug, since that would match more closely with how we expect the predicates to be defined during trait solving. You could also in theory have for<'a> where<I: Trait> I::Item<'a>: Debug, for example (thought I can't think of a reason for that off the top of my head).

@tema3210
Copy link
Author

@jackh726

First, I'd like for this to not really be needed in most cases if ever. We should be able to use some form of implied bounds here. We've had some discussion around a-mir-formality about this.

I'm not sure what do you want here. With for<'_> syntax for closures we can specify that a closure should be generic over lifetimes and this feature plays nicely with that. Plain closures already can be inferred to be both generic and non - generic (I'm not sure about exact rules though) - you want to specify an algorithm?

Second, I personally prefer for<'a> where <'i: 'a> I::Item<'a>: Debug, since that would match more closely with how we expect the predicates to be defined during trait solving. You could also in theory have for<'a> where<I: Trait> I::Item<'a>: Debug, for example (thought I can't think of a reason for that off the top of my head).

Such syntax feels strange with closures: for<'a> where<'b: 'a> |arg: &'a T| ....

@JanBeh
Copy link

JanBeh commented Jul 22, 2023

First, I'd like for this to not really be needed in most cases if ever. We should be able to use some form of implied bounds here.

Related to HRTBs with two lifetimes and implied bounds:

@oxalica
Copy link

oxalica commented Jan 18, 2024

@jackh726

First, I'd like for this to not really be needed in most cases if ever. We should be able to use some form of implied bounds here. We've had some discussion around a-mir-formality about this.

I'm trying to define a trait abstraction for std::thread::scope interface. But it seems impossible to be defined without bounds 'env: 'scope. It can be implicitly inferred with freestanding functions, but not inside trait with GATs.

playground

trait SupportScoped {
    type Scope<'scope, 'env: 'scope>;

    fn scope<'env, F>(f: F)
    where
        for<'scope> F: FnOnce(&'scope Self::Scope<'scope, 'env>);
}

struct Thread;

impl SupportScoped for Thread {
    type Scope<'scope, 'env: 'scope> = std::thread::Scope<'scope, 'env>;

    fn scope<'env, F>(f: F)
    where
        for<'scope> F: FnOnce(&'scope Self::Scope<'scope, 'env>),
        //             ^ error[E0478]: lifetime bound not satisfied
    {
        std::thread::scope(f);
    }
}

I think the explicit type of scope should be like this, which is impossible to write without this RFC:

fn scope<'env, F>(f: F)
where
    for<'scope where 'env: 'scope> F: FnOnce(&'scope Self::Scope<'scope, 'env>);

@lcnr lcnr added the T-types Relevant to the types team, which will review and decide on the RFC. label May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC. T-types Relevant to the types team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants