Note that the @escaping is unnecessary in this case; by being inout it's structurally not a top-level parameter type (and therefore implicitly escaping), and it also doesn't make sense to have a non-escaping inout parameter. But we should diagnose it better.

@slavapestov also pointed out that the existing diagnostic for things like Array<@escaping () -> Void> isn't great either.

Comment by Matthew Johnson (JIRA)

@jrose I don’t believe this code works without `@escaping` either though. I’m on my phone right now and will try without it when get backup my computer.

Comment by Matthew Johnson (JIRA)

@belkadan as it turns out this works when the function is meeting a protocol requirement, but crashes the compiler when it does meet a protocol conformance, this the following code crashes the compiler:

protocol P {
    associatedtype T
    func foo(t: inout T)
}
struct S: P {
    func foo(t: inout () -> Void) {}
}

An attempt to capture a copy of the function isn't required and doesn't appear to be the problem.

Can you file a separate issue for that, then? It's still worth improving the diagnostic(s) if someone tries what you tried.

Comment by Matthew Johnson (JIRA)

Sure. For reference: https://bugs.swift.org/browse/SR-9624

Comment by Ray Fix (JIRA)

CodaFi (JIRA User) I saw your invitation on the (now defunct) try! Swift slack. It seems like maybe you had some hints about fixing this one. Any chance you could share those hints here?

My understanding is that the diagnostic should be changed to say something like:

"@escaping is not needed here" or perhaps "@escaping can only be applied to top-level types" If there is a particular wording you have in mind, please let me know.

It seems like the fix has something to do with determining if the type is a top level type and emit the warning (error?) if it is not. Will this PR also need to address `Array<@escaping () -> Void>` @belkadan or is that a different PR?