Do you think this ~Escapable capability should co-exist with the @nonescaping attribute, or they are mutually exclusive? Because I think both approaches have their drawbacks.
struct FuncWrapper<Argument, Result> {
var function: (Argument) -> Result
init(function: @resultDependsOn (Argument) -> Result) { ... }
}
This type can be "escaping" when the underlying function is escaping, and "nonescaping" when it isn't.
So we can't always mark it with ~Escaping, and the @nonescaping attribute is a better option here. However, at the same time, we can't express a generic constraint for Argument to be escaping or non-escaping.
Besides escapability is not really binary for structural types. A function can escape one item of a tuple, but not the other one. There are three underscored attributes for expressing escapability, and they do excelent job in terms of granularity, but there is room for improvement semantically, syntactically and lexically here.
IMO, one of the goals should be a common ground and syntax for general escapability rules for function and non-function types. This way we can eliminate issues such as this one.