lcnr covers for<...> where<...> aka for<... where ...> as pertains to #25860; basically in that context it means
- You start with something well-formed, that may have implicit bounds
- You carry those around as
for<where>bounds- Maybe explicitly, maybe just internally
- When you replace (and/or split) lifetime parameters, they hold on to their
for<where>bounds- Even if in replaced form, they are no longer implied by the rest of the signature
That last part is the key difference as you can end up with something like a
for<'out where 'in: 'out> fn(&'out &'static (), &'in T) -> &'out T
Which is higher-ranked but has bounds beyond those implied by well-formedness. In the example, the bound came from originally having a &'out &'in () as the first parameter, and you return the second parameter. Without the bound, you could from here change 'out to 'static and extend the lifetime of the second parameter unsoundly. With the bound, making that change forces 'in to be 'static as well.
I think we'll want an explicit form anyway though, because sometimes higher-ranked but-bound lifetimes solve other problems, and the only way we have to get them now is by exploiting implied bounds in hacky ways. Such a workaround is part of the pending scoped threads implementation.
There's an RFC PR but I'm not sure it's thorough enough in its current form to get traction. The comment is a bit disheartening; I'm of the view that as much things as possible which are implicit should have an explicit form (preferably with a 1-to-1 desugaring). [1]
On the up (?) side, I don't think a purely implicit form can actually fix things like #25860 without full-program analysis/data-flow (or some rather artificial restrictions around not passing stuff with for<where> bounds between functions or the like).
-
The inscrutable errors, undocumented algorithms, and obscure hints and tricks used to hack around both of them highlighted in this very thread being a prime example of why. ↩︎