I have run into nondescript compiler crashes (like segmentation faults, etc.) when using local functions to do certain things, like wrapping the parent function’s escaping closure arguments in other closures that capture variables from the parent function’s local scope, especially when those variables themselves are function types that do the wrapping, and therefore take closures as arguments. (Of course, all of these closures taking generic arguments conforming to protocols with associated types made things extra interesting.)
I don’t know if this makes local functions actively harmful, or if it means function types in capture lists need to support @escaping, but it does remind me to go back and try to reproduce those weird issues in a sample project or playground page so I can make a bug report to Apple. Jonathan > On Oct 27, 2017, at 12:29, Slava Pestov via swift-evolution > <[email protected]> wrote: > > I mean, we could remove a lot of language features without giving up turing > completeness. But I’ve personally used local functions in multiple languages > and found them useful. I certainly don’t see why the feature is actively > harmful, which is the criteria for introducing a source breaking change in > Swift 5. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
