> I think requring trailing closures to be @noescape would take away some very > compelling use cases for them. In particular, you would lose the ability to > use trailing closures for asynchronous code, like completion functions. I, > for one, would be sad to lose those—they are often some of the largest, most > block-like pieces of code that you put into a closure.
I, too, would be sad about that — but aside from a syntactic/stylistic choice, there aren’t any important-to-the-compiler semantics conveyed by the trailing closure, are there? > > At the same time, many of the things which people seem to think shouldn't be > trailing closures, like `map` blocks, seem like good candidates for early > returns or other control flow. I *don’t* think `map` blocks should be able to control the outside scope. Map should map, that is transform. `forEach` should probably be able to do outside function control flow, and the use of trailing closure would be consistent with the Rule of Kevin. > Basically, if you imagine a Venn diagram of "closures it would be useful to > break out of early" and "closures you might want to use trailing closure > syntax with", I don't think there's a particularly large amount of overlap > between the two circles. Aside from `map`, do you have other examples where there is no overlap? — Radek _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
