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

Silent demotion of lifetime in analysis causes confusing message #21508

Closed
dhardy opened this Issue Jan 22, 2015 · 6 comments

Comments

Projects
None yet
5 participants
@dhardy
Copy link
Contributor

dhardy commented Jan 22, 2015

See StackOverflow question.

Summary: the compiler accepts a trait impl function returning a &'static str when the trait requires only &'a str, 'a being the life of the object, but then assumes the lifetime of the returned value is only &'a str despite direct call (not via trait).

Possible solutions I see:

  1. Do not demote the lifetime of a function when called via the object (not the trait), but keep both versions of the function (i.e. lifetime &'static when called via the object and lifetime &'a when called via the trait). This is likely confusing, so (2) may be better.
  2. Make it an error to implement a trait function with too long a lifetime.

@huonw huonw added the A-lifetimes label Jan 22, 2015

@huonw

This comment has been minimized.

Copy link
Member

huonw commented Jan 22, 2015

cc @nikomatsakis; this is the "subtyping" rule, right?

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Feb 2, 2015

Yes, this is the subtyping rule. I'm not sure whether changes are needed here, but if we were to change anything I would want to get stricter about the correspondence between the trait and impl.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Feb 2, 2015

There are other places -- notably where-clauses -- where we absolutely cannot require a 1-to-1 correspondence. But in method signatures we likely could. It's a bit trickier than it might sound.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Feb 4, 2015

Nominating. We have to decide what semantics we want here I guess.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Feb 5, 2015

P-high, not required for 1.0. (But we would take a patch if we happen to get one before 1.0; otherwise the current semantics is stuck).

@pnkfelix pnkfelix added P-medium and removed I-nominated labels Feb 5, 2015

@steveklabnik

This comment has been minimized.

Copy link
Member

steveklabnik commented Mar 4, 2016

But we would take a patch if we happen to get one before 1.0; otherwise the current semantics is stuck).

Well, a loooong time after 1.0, I guess this is stuck here, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.