Change:
declare_lint! { pub HR_LIFETIME_IN_ASSOC_TYPE, <del> Warn, </del> <ins> Deny, </ins> "binding for associated type references higher-ranked lifetime  that does not appear in the trait input types" }

Discussion:
This is the summary issue for the future-compatibility warning and other related errors. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our [breaking change policy guidelines][]. The warning is issued in two cases. First, if you have a where-clause where a higher-ranked lifetime appears only in the associated type. This most commonly occurs when the lifetime appears in the return type for one of the closure traits: But could also occur in other associated type bindings: The second situation is when you have a type with a lifetime that appears only in the return type: Note that it is perfectly fine for a higher-ranked lifetime to appear in an associated type or function return type if it also appears in the trait inputs or function arguments: In cases where the lifetime appears only in the return type, it is also generally better to use : These constructs are being rejected as part of the fix for issue rust-lang/rust. This is a soundness bug that concerns cases like these. In general, all higher-ranked lifetimes that are used in the value of an associated type (and in this case, the function return type is an associated type) must also appear in the trait's input types. This constraint is already enforced for impls, but enforcement was overlooked for where-clauses. These sorts of where-clauses and types are not only ill-formed, they are useless. For example, now that is fixed, there are no types that could satisfy such a where-clause, nor are there any functions with a type like (see next section for more details). Once is fully fixed, there are some cases of code that will yield errors which will not currently receive warnings. The crux of the problem concerns lifetime parameters that only appear in the return type of a fn declaration -- these are changing to no longer be considered "higher-ranked" (or "late-bound"). This change is usually harmless, but it can trigger compilation errors of various kinds. For engineering reasons, there are some cases where it was not possible to issue warnings, though we will try to cause the error message to direct people to this issue.

Here is an example of an affected function: Merely calling this function should work as before. But assigning it to a fn pointer variable will trigger an error, depending on the type of that variable: Another, more subtle, error can occur when a function is stored into a variable and then invoked multiple times: Essentially, the change is that each time you reference (directly!), there is now a single lifetime assigned for its parameter , no matter how many times you call it. In cases like above, we need to assign distinct references to each call, so we have to reference twice. Also related is , which can cause these warnings to be issued more frequently than one might expect. In particular, due to , the compiler fails to recognize certain equivalences around lifetime parameters. For example, this function: probably ought to be considered equivalent to this function: and both of them ought to be usable in a context where is required. But because of , only the version that explicitly uses is considered to satisfy the higher-ranked type. The typical process is as follows: at the beginning of each 6-week release cycle, the Rust compiler team will review the set of outstanding future compatibility warnings and nominate some of them for Final Comment Period. Toward the end of the cycle, we will review any comments and make a final determination whether to convert the warning into a hard error or remove it entirely.
Let's move this to Deny by default.
fcp close I move that we make this a hard error. This is a soundness-related change. The change to Deny is in PR and is currently being tested for impact.
Team member has proposed to close this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Is this ready to be closed?
it is deny-by-default now, but I have not yet opened the PR to remove the underlying problem. It is all but ready though, hopefully I will get to it today.
:bell: This is now entering its final comment period, as per the .

:bell: psst I wasn't able to add the label, please do so.
The final comment period is now complete.
No more compat warnings since .
I think the reason for is is an association type. Why the is an association type and not a generic type? In my opinion, function pointers are similar to: This shows that the works well as a generic parameter. So what if rewrite into And then only to push ?
If the changes as generic parameters, appears in the input requirements are not necessary, because in addition to the function. No same type can implement different lifecycle So the as an association type is just an error