<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Thu, Dec 31, 2015, at 04:46 PM, Joe Groff wrote:<br></div>
<blockquote type="cite"><div> </div>
<div><blockquote type="cite"><div>On Dec 31, 2015, at 4:26 PM, Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>> wrote:<br></div>
<div> </div>
<div><div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">On Thu, Dec 31, 2015, at 01:40 PM, Michel Fortin wrote:</span></span><br></div>
<blockquote style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant: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;" type="cite"><div>Le 30 déc. 2015 à 16:40, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br></div>
<blockquote type="cite"><div>On Wed, Dec 30, 2015, at 01:33 PM, Joe Groff wrote:<br></div>
<blockquote type="cite">Another possibility I've thought of is defining `defer { val }` to guarantee that val remains alive until the defer fires on scope exit. That might let us leave `defer` as the one "guarantee something happens exactly at scope exit" language construct.<br></blockquote><div> </div>
<div>Oh that's cute. I'd probably want to say `defer { _ = val }` though, to make it obvious that this is intentional.<br></div>
</blockquote><div> </div>
<div>Or you could make it even more obvious what this is by giving that feature a name. For instance:<br></div>
<div> </div>
<div><span style="white-space:pre;"></span>defer { _fixLifetime(val) }<br></div>
<div> </div>
<div>The good thing about this one is that it already works, because that's what `withExtendedLifetime` does internally. Also, if you search a bit, you'll end up here with a nice explanation of what that function does.<br></div>
<div><a href="https://github.com/apple/swift/blob/8d9ef80304d7b36e13619ea50e6e76f3ec9221ba/stdlib/public/core/LifetimeManager.swift#L45">https://github.com/apple/swift/blob/8d9ef80304d7b36e13619ea50e6e76f3ec9221ba/stdlib/public/core/LifetimeManager.swift#L45</a><br></div>
<div> </div>
<div>So why not simply remove the underscore?<br></div>
</blockquote><div> </div>
<div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Because it's not a very good API? Having some magic function called `fixLifetime()` that keeps values alive is a little weird. `withExtendedLifetime()` is also slightly weird, but it makes more sense than fixLifetime() does, since withExtendedLifetime() is the specific solution to the problem of "I need to ensure this value remains alive for this entire scope because reasons".</span></span><br></div>
<div> </div>
<div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">I'd much rather just see the syntax `_ = val` be converted into `Builtin.fixLifetime(val)` because the only reason to write an expression like that is because you want to make sure the value is still alive at that point (that and because it's not unreasonable for people to assume that `_ = val` will keep the value alive, so it would be nice to make that assumption actually be correct).</span></span><br></div>
</div>
</blockquote></div>
<div> </div>
<div>I don't think this is obviously true. `val` could be a computed property you just want to force the side effects for. (Computed properties with side effects maybe aren't a great idea, but there are some in AppKit/UIKit.)<br></div>
</blockquote><div> </div>
<div>I see two possibilities here:<br></div>
<div> </div>
<div>1. If it's a computed property, fix the lifetime of the return value anyway. I don't think this is particularly helpful though, although all it would do in practice is prevent early-release if the computed property is inlined, or<br></div>
<div>2. If it's a computed property, just don't fix the lifetime. It seems fine to me to say `_ = localVar` has the implicit side-effect of fixing the lifetime of localVar, and if you say `_ = computedProperty` then that's just the pre-existing behavior of evaluating the computed property for its side-effects. No need to fix the lifetime of the computed property result.<br></div>
<div> </div>
<div>Incidentally, does it makes sense to talk about fixing the lifetime of stored properties? I assume that only really matters for local variables, because stored properties are tied to `self`.<br></div>
<div> </div>
<div>-Kevin</div>
</body>
</html>