cc @milseman. The actual behavior we want here is that @escaping is a property of the parameter, not the function type, but we don't currently allow you to write @escaping on typealiases. I think there's another JIRA or Radar for that.

I thought this was an actual bug, but in fact in TypeCheckType.cpp, we resolve function types differently if they appear inside another function context. This seems inconsistent and weird. It would be better to allow @escaping on type alias types, as Jordan said.

Comment by David Grove (JIRA)

The thing that seemed broken to me is that whether a parameter's type is declared with or without using a typealias impacts whether or not the parameter gets the default @NoEscape.

typealias _swift_data_applier = (Int) -> Void
func bogus_error(_ block: _swift_data_applier) { block(10) }
func works_fine(_ block: (Int) -> Void) { block(10) }

The block parameter for bogus_error is considered to be @escaping, but the one for works_fine is considered to be @NoEscape. I would have expected both to be @NoEscape.

Yeah, we discussed this today and should have a fix soon. This is definitely a bug.

Comment by David Grove (JIRA)

fix confirmed.