> On Feb 7, 2017, at 11:56 AM, Andrew Trick <atr...@apple.com> wrote: > >> >> On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >> >>> On Feb 6, 2017, at 11:44 AM, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>> >>>> On Feb 6, 2017, at 11:25, Joe Groff via swift-dev <swift-dev@swift.org >>>> <mailto:swift-dev@swift.org>> wrote: >>>> >>>> >>>>> On Feb 6, 2017, at 11:22 AM, Michael Gottesman <mgottes...@apple.com >>>>> <mailto:mgottes...@apple.com>> wrote: >>>>> >>>>> Here is my suggestion: >>>>> >>>>> 1. We assume by default the leaking case. >>>>> 2. We change noreturn functions from C to maybe have a special semantic >>>>> tag on them that says that cleanups should occur before them (i.e. >>>>> UIApplicationMain). >>> >>> I'm not sure what you mean by this. Functions from C exist in both groups, >>> and I don't see why one assumption is better than the other. >>> >>> >>>> >>>> I feel that "clean up before" is the safer ground case, and if we do any >>>> work to whitelist a group, it should be for the common "leakable" >>>> noreturns, like exit/_exit/abort/fatalError. That way, we momentarily burn >>>> some pointless cycles in the case we get it "wrong" rather than >>>> permanently leak memory. >>> >>> I don't like this because of the reverse issue: under -Onone, you may want >>> to pop back up the stack in the debugger and see what values you had, and >>> they won't be available. It's almost always possible to get things released >>> sooner; usually more awkward to get them to stay alive. >> >> On the other hand, this is safe to do in the short term. We can special case >> asserts. One thing to consider though is if this should be provided to >> users. If not, we can just use semantics. Otherwise, we would need to >> discuss how to surface this at the language level. >> >> Michael > > Sorry I didn't jump in yesterday. I'm afraid I don't follow most of the > reasoning expressed in the thread. I do completely understand Jordan's points. > > 'noreturn' functions are called from may-return functions. Guaranteeing > cleanup would result in inconsistent behavior as a result of optimization. > > The optimizer can always shorten lifetimes when it determines that the caller > can't access the object. But I don't see what that has to do with 'noreturn'. > > I agree that we *could* add a special "cleanup before" semantic tag for some > C functions, but I'm not aware of a need to do that and there are definite > drawbacks.
No worries. (TBH I was just trying to get a decision and was posting straw men proposals). Basically after further talk off list, we got in agreement to go with the scope splitting approach (i.e. no cleanups). What I really just wanted was something definitive that I could explicitly document. I added a small blurb to ./docs/ARCOptimization.*. I need to add an example and make it slightly clearer. Michael > > -Andy
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
