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

Fn trait associated type (return type) considered unconstrained #86934

Closed
afranchuk opened this issue Jul 7, 2021 · 6 comments
Closed

Fn trait associated type (return type) considered unconstrained #86934

afranchuk opened this issue Jul 7, 2021 · 6 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@afranchuk
Copy link

afranchuk commented Jul 7, 2021

I tried this code:

struct S<F>(F);

impl <'a, F, G> S<F>
where
    F: Fn(&'a u8) -> G
{
    fn call(&mut self) -> G {
        (self.0)(&1)
    }
}

I expected to see this happen: G should be considered a constrained type.

Instead, this happened:

error[E0207]: the type parameter `G` is not constrained by the impl trait, self type, or predicates

Note that if you use '_ as the lifetime instead of 'a, it works. It also works if there is no lifetime on the input parameter (e.g. if it's not a reference). However I want to constrain G to the same lifetime (eventually) so that's not an option. Is this an issue due to some lifetime assumptions about the return type from Fn traits, specifically that having G: 'a makes it unconstrained as it can't reason about that?

This is identical for FnOnce and FnMut as well.

Meta

rustc --version --verbose:

rustc 1.53.0 (53cb7b09b 2021-06-17)
binary: rustc
commit-hash: 53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b
commit-date: 2021-06-17
host: x86_64-unknown-linux-gnu
release: 1.53.0
LLVM version: 12.0.1
@afranchuk afranchuk added the C-bug Category: This is a bug. label Jul 7, 2021
@jonas-schievink jonas-schievink added A-associated-items Area: Associated items (types, constants & functions) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 7, 2021
@b-naber
Copy link
Contributor

b-naber commented Jul 7, 2021

@rustbot claim

@b-naber
Copy link
Contributor

b-naber commented Jul 8, 2021

This seems to not be a bug, but an intentional error, see #25041

@b-naber
Copy link
Contributor

b-naber commented Jul 8, 2021

@rustbot release-assignment

@b-naber
Copy link
Contributor

b-naber commented Jul 8, 2021

Maybe to summarize why this is an error. The rules for constrained parameters are in this rfc:

If T appears in the impl trait reference,
  then: T is constrained

If T appears in the impl self type,
  then: T is constrained

If <T0 as Trait<T1...Tn>>::U == V appears in the impl predicates,
  and T0...Tn are constrained
  and T0 as Trait<T1...Tn> is not the impl trait reference
  then: V is constrained

Since the lifetime parameter 'a is unconstrained when we determine whether G is constrained the third rule does not apply.

@afranchuk
Copy link
Author

Okay, that's what I suspected. I guess I really want a more powerful for<'a> that can apply to the return type (which I've discussed before on Zulip). It'd be very helpful in the future if the error message indicated exactly what makes a particular type unconstrained.

@Dylan-DPC
Copy link
Member

Closing this, as it's intentional as per #86934 (comment)

@Dylan-DPC Dylan-DPC closed this as not planned Won't fix, can't repro, duplicate, stale Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants
@jonas-schievink @afranchuk @b-naber @Dylan-DPC and others