<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 14, 2016, at 1:29 PM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">We have the withFixedLifetime API in the standard library today.<br class=""><br class="">withFixedLifetime(ownningReference) {<br class="">}<br class=""><br class="">Users can rely on that a stored reference in a class is not ultimately released during a method call on that class instance if they can guaranteed that nobody stores to that reference.<br class=""><br class="">The compiler honor withFixedLifetime today (if not that is a bug).<br class=""><br class="">Your point is that this needs to be made clear.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Yeah, I think withFixedLifetime is probably not a good enough tool; at the very least, you need to reason about indirect references. (e.g. if the object is held by an array element or a class property, then the array/instance itself needs to be held precisely, etc.) It’s probably better for local values than a precise-lifetime attribute on local variables, though, assuming withFixedLifetime works for value types, and assuming it doesn’t actually cause reference-counting traffic itself.</span></div></div></blockquote></div><div class=""><br class=""></div><div class="">The compiler should not be allowed to extend any object lifetimes past a fixed-lifetime marker.</div><div class=""><br class=""></div><div class="">I think it is necessary for the user of the proposed unsafe API to provide a fixed lifetime scope on an owning object, which may have levels of indirection. It’s also necessary for the user to avoid mutating any references that participate in that ownership chain within the fixed lifetime scope.</div><div class=""><br class=""></div><div class="">I don’t think this is an API that we want to promote. In the long run, I imagine a safe/automatic approach (a stored property can be obtained @guaranteed if it’s parent is transitively @guaranteed and is immutable). But that requires some language support and meanwhile we need a backdoor for bypassing ARC in special circumstances.</div><div class=""><br class=""></div><div class="">Andy</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>