Description
This is mostly a question for @compiler-errors (and really just an edition-guide issue). This is regarding the maybe-incorrect suggestion for impl_trait_overcaptures
in the following specific scenario:
where the general code looks like:
impl<RDF> RDFParser<RDF>
where
RDF: FocusRDF,
{
//................
pub fn instances_of(
&self,
object: &RDF::Term,
) -> Result<impl Iterator<Item = RDF::Subject>, RDFParseError> {
let values = self
.rdf
.subjects_with_predicate_object(&Self::rdf_type(), object)
.map_err(|e| RDFParseError::SRDFError { err: e.to_string() })?;
Ok(values.into_iter())
}
}
This generates the impl_trait_overcaptures
with maybe-incorrect applicability.
warning: `impl Iterator<Item = <RDF as srdf_basic::SRDFBasic>::Subject>` will capture more lifetimes than possibly intended in edition 2024
--> src/srdf_parser/rdf_parser.rs:65:17
|
65 | ) -> Result<impl Iterator<Item = RDF::Subject>, RDFParseError> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= warning: this changes meaning in Rust 2024
= note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/rpit-lifetime-capture.html>
note: specifically, these lifetimes are in scope but not mentioned in the type's bounds
--> src/srdf_parser/rdf_parser.rs:63:9
|
63 | &self,
| ^
64 | object: &RDF::Term,
| ^
= note: all lifetimes in scope will be captured by `impl Trait`s in edition 2024
help: use the precise capturing `use<...>` syntax to make the captures explicit
|
65 | ) -> Result<impl Iterator<Item = RDF::Subject> + use<RDF>, RDFParseError> {
The question I have is that I do not see this scenario described in https://doc.rust-lang.org/nightly/edition-guide/rust-2024/rpit-lifetime-capture.html, and thus left being uncertain about why it thinks it is maybe incorrect. I assume it is something to do with the associated types, but it wasn't immediately obvious how to minimize this scenario.
If this isn't already documented on https://doc.rust-lang.org/nightly/edition-guide/rust-2024/rpit-lifetime-capture.html about why it might be wrong to blindly follow the compiler, would it be possible to describe the scenario and what considerations the author should take before accepting the suggestion?
Meta
rustc --version --verbose
:
rustc 1.84.0-nightly (143ce0920 2024-11-10)
binary: rustc
commit-hash: 143ce0920a2307b19831160a01f06f107610f1b2
commit-date: 2024-11-10
host: aarch64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.3