> The only way I see this working is if the trailing closure syntax has *other* > semantics as well. For example, there’s been a discussion about allowing > specially marked closures to return/break/continue in the scope of the caller > function, not the closure’s scope (like Ruby’s blocks do). Now, that would > make a bit more sense. You’d have a special attribute (can’t think of a name, > but let’s stick with your @trailing), that would imply: > > - required trailing closure syntax > - @noescape, I think > - and return/break/continue affects outside functions > > And you could use that to make your own pseudo-language-constructs. This > would enforce trailing closure syntax, and nothing else could use trailing > closure syntax. > … > What do you think?
First of all, you're right that a block that could return/break/continue/etc. would need to be @noescape. Otherwise, what would those keywords do if the function had already returned? 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. 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. 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. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
