-
Notifications
You must be signed in to change notification settings - Fork 13k
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
GATs: repeating not-locally-required bounds on impls? #91348
Comments
Okay, I'm wrong that a workaround is needed: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=9c22eb9f05bc249d062e794a2f9b49ec That said, I'm still not convinced the bound should be necessary. |
Reading through the issue again, I would like to say a couple of things. First, the error message for missing bound in the trait is clear about what to do (though it would be helpful if it also mentioned why / referenced extra doc), however the same is not true for implementations: here it's less clear what bound is required ( Further, putting a Finally, the point of #87479 IIUC is that In that case, the chosen solution does not appear "rustic". I would expect, then, that (1) the bound is not required in the trait, but a lint warns that it is likely wanted (allowing opt-out) and (2) that writing an |
Okay, I'll try to respond to points individually, since there a lot here.
While it's not true to say that every type for a GAT will need the
You're completely right here; the error messages are this aren't great (because it's hard). But that should get better in time.
This works for me.
Right, the required bounds basically boil down to the fact that impls can't have extra bounds, so we have to do our best to infer how a GAT will be used to allow the most flexibility in impls.
This was discussed quite a bit on/around #87479. The idea is to eventually make this "implied" and not make the user write these bounds at all. But in order for this to not be a breaking change, we have to require them now. If we've done the lint correctly and have the correct assumptions, then there shouldn't be any code that won't work with the required bounds but would otherwise (and vice versa) - but we can't necessarily guarantee that, so we can only be potentially more restrictive than for now. Another alternative is to just do nothing - or "only" warn. This isn't ideal because errors around these errors can be difficult to diagnose and fix. And, moreso, if a library publishes a trait without these bounds, downstream crates can't do anything about it and it can severely limit impls. Please let me know if I've missed anything here. Ultimately, there are tradeoffs here and I want to hear about how the outlives lint impacts different use cases. |
No, that's a great response, thanks. So somehow I had trouble putting the bounds on the impl. Given better error messages this wouldn't have been an issue.
The point is simply that it was not initially clear the bounds on the trait are required to cover all possible implementations:
Are the situations for GATs and trait method parameters not analogous? Why then must unused bounds be specified on the impls of GATs but not trait method parameters? |
where Self: 'a
bound breaks usage with possible-iterators…r=nikomatsakis GATs outlives lint: Try to prove bounds Fixes rust-lang#91036 Fixes rust-lang#90888 Fixes rust-lang#91348 (better error + documentation to be added to linked issue) Instead of checking for bounds directly, try to prove them in the associated type environment. Also, add a bit of extra information to the error, including a link to the relevant discussion issue (rust-lang#87479). That should be edited to include a brief summary of the current state of the outlives lint, including a brief background. It also might or might not be worth it to bump this to a full error code at some point. r? `@nikomatsakis`
See: #87479
So, I believe #89970 broke my code kas-text (nightly rustc +
--feature gat
).This isn't true in general, though it may be in specific instances. My code (reduced) exemplifies this perfectly:
Here,
font_tokens
may return an iterator over an instance ofSelf
... but it also may not (&str
does not have any formatting).A possible workaround in the impl is to write a custom iterator with a reference to the&str
anyway, but this seems unnecessary.The text was updated successfully, but these errors were encountered: