I’ve said this Michael in person, but I’ll put it on the thread for others to see:
I don’t think modeling this is worth the increase in complexity. There’s a partial workaround for anyone who notices this being a problem, which is to put any expensive work in a ‘do’ block. And actually emitting cleanups before a call to, e.g., dispatch_main would be a change in semantics, which could both break existing programs and makes the language a bit harder to reason about. The current rule that “defers happen at the close brace, releases may happen sooner” is simple. (We certainly would not want to make ‘defer’s happen before calling dispatch_main, though perhaps we should warn that they will never be executed.) Furthermore, we have no good way to distinguish these two kinds of functions (dispatch_main vs. abort), even less so when many of them come in from C. We’d have to invent some new kind of attribute just for this case. (Admittedly, since functions like dispatch_main are rare, the attribute doesn’t have to be pretty.) I think this is just a theoretical concern, though admittedly one Michael is running into doing his work on explicit ownership in SIL, and I don’t think we need to consider changing any behavior here. Jordan > On Feb 6, 2017, at 09:48, Michael Gottesman via swift-dev > <swift-dev@swift.org> wrote: > > One thing that is an issue that has come up with ownership is that at the SIL > level we do not distinguish in between exceptional noreturn functions and > exceptional return functions. > > This is important since in the non-exceptional case, we would like to clean > up all of the values used in the current function before calling the > no-return function. An example of such a function is dispatch_main from > libdispatch. In the exceptional case though, we are ok with leaking since the > program will be exiting. Beyond reducing code size (I guess?), the argument I > have heard for this is that this will allow for people to examine values in > the debugger since we will not have cleaned things up before the abort is > called. > > From what I can tell, if we are going to distinguish in between these cases, > then we need a distinction in between the two baked into the compiler. > Thoughts? I have code written that will enable either case to be handled as > long as I can distinguish in between them at the SIL level. > > Michael > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
