That sounds like a bug, and it could occur with closure expressions also, since at the SILGen level and below they’re basically the same thing. Please file a bug if you come up with a reduced test case.
Slava > On Oct 27, 2017, at 4:00 PM, Jon Gilbert <swiftevolut...@jongilbert.com> > wrote: > > 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 >> <swift-evolution@swift.org> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
