You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure whether this is code that ought to be valid but the lifetime inference isn't clever enough for, or if it's invalid but subtyping makes it hard to give a good error message about why. This part is reduced from code in the regex crate (specifically Captures):
use std::ops::Index;structStrHolder<'a>(&'astr);impl<'a>Index<&'astr>forStrHolder<'a>{typeOutput = str;fnindex<'b>(&'bself,_name:&str) -> &'bstr{self.0}}
And this tries to use it:
pubfnproblem(s:&str) -> usize{let sh = StrHolder(s);
sh["whatever"].len()}
Which leads to this:
bounds_thing.rs:10:24: 10:25 error: cannot infer an appropriate lifetime for automatic coercion due to conflicting requirements [E0495]
bounds_thing.rs:10 let sh = StrHolder(s);
^
bounds_thing.rs:10:14: 10:23 note: first, the lifetime cannot outlive the expression at 10:13...
bounds_thing.rs:10 let sh = StrHolder(s);
^~~~~~~~~
bounds_thing.rs:10:14: 10:23 note: ...so that a type/lifetime parameter is in scope here
bounds_thing.rs:10 let sh = StrHolder(s);
^~~~~~~~~
bounds_thing.rs:10:24: 10:25 note: but, the lifetime must be valid for the expression at 10:23...
bounds_thing.rs:10 let sh = StrHolder(s);
^
bounds_thing.rs:10:24: 10:25 note: ...so that auto-reference is valid at the time of borrow
bounds_thing.rs:10 let sh = StrHolder(s);
^
If the impl started like this (which is the PR I'm going to send to regex) then it would work, because there wouldn't be a constraint between the index string and the region parameter on problem (in addition to Index requiring the returned str to have the same lifetime as the StrHolder):
impl<'a,'i>Index<&'istr>forStrHolder<'a>
The weird part is that making this change, to explicitly coerce the &'static str literal to an unspecified maybe-shorter lifetime, also fixes it:
sh["whatever"as&str].len()
And this is why I'm wondering if it's more than just a quality-of-error-message issue.
The text was updated successfully, but these errors were encountered:
In the original context, the impl with the not-quite-right lifetimes was in an external crate I didn't write; I eventually figured out what was going on after enough trial-and-error (and I just now got around to filing rust-lang/regex#143), but it would be nice if the errors could be made clearer.
Also, the fact that explicitly casting a &str to &str (at a point in the code that isn't in any of the error messages, even) affects whether there's a type error makes me wonder if something more is going on here — I can see that it's not conceptually different from needing explicit casts with borrowed/boxed traits, but normally the borrow checker can figure out how to infer them for regions.
I can't seem to reproduce today, with the below code, so I am going to close. If you can provide an example which reproduces today, please let us know and we'll reopen,
use std::ops::Index;structStrHolder<'a>(&'astr);impl<'a>Index<&'astr>forStrHolder<'a>{typeOutput = str;fnindex<'b>(&'bself,_name:&str) -> &'bstr{self.0}}pubfnproblem(s:&str) -> usize{let sh = StrHolder(s);
sh["whatever"].len()}
I'm not sure whether this is code that ought to be valid but the lifetime inference isn't clever enough for, or if it's invalid but subtyping makes it hard to give a good error message about why. This part is reduced from code in the
regex
crate (specificallyCaptures
):And this tries to use it:
Which leads to this:
If the
impl
started like this (which is the PR I'm going to send toregex
) then it would work, because there wouldn't be a constraint between the index string and the region parameter onproblem
(in addition toIndex
requiring the returnedstr
to have the same lifetime as theStrHolder
):The weird part is that making this change, to explicitly coerce the
&'static str
literal to an unspecified maybe-shorter lifetime, also fixes it:And this is why I'm wondering if it's more than just a quality-of-error-message issue.
The text was updated successfully, but these errors were encountered: