> On Feb 6, 2017, at 11:04 AM, Michael Gottesman <mgottes...@apple.com> wrote: > >> >> On Feb 6, 2017, at 10:04 AM, Joe Groff <jgr...@apple.com> wrote: >> >> >>> On Feb 6, 2017, at 9:48 AM, 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. >> >> The interesting distinction here to me strikes me as being the temporal >> rather than exceptional nature of the exit. _exit(2) isn't an "exceptional" >> noreturn per se, but you'd still want to leak cleanups before it since the >> program's termination comes immediately after the call. If it's a profitable >> distinction to be made, I think there are few enough immediate-exit >> primitives like exit, abort, fatalError, etc. that we could probably >> whitelist them with a @_semantics attribute for now, and maybe use an early >> SIL pass to propagate the attribute in obvious cases where a function is a >> simple wrapper around one of those functions. > > I am fine with either approach as long as we make a decision. > > But just to bring it up in the discussion, Alexis brought up in chat an > interesting point, namely what about higher level functions? I guess we don't > care about that case?
For higher-order functions, I think we should optimize for the common case that their generic parameters are inhabited. Like Jordan said, micromanaging the policy here is already tottering on the edge of diminishing returns for first-order noreturns; trying to accommodate every possibility of injecting an uninhabited type somewhere definitely feels like overkill. -Joe
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
