> On Dec 31, 2015, at 4:26 PM, Kevin Ballard <[email protected]> wrote:
> 
> On Thu, Dec 31, 2015, at 01:40 PM, Michel Fortin wrote:
>> Le 30 déc. 2015 à 16:40, Kevin Ballard via swift-evolution 
>> <[email protected]> a écrit :
>>> On Wed, Dec 30, 2015, at 01:33 PM, Joe Groff wrote:
>>>> 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.
>>> 
>>> Oh that's cute. I'd probably want to say `defer { _ = val }` though, to 
>>> make it obvious that this is intentional.
>> 
>> Or you could make it even more obvious what this is by giving that feature a 
>> name. For instance:
>> 
>>      defer { _fixLifetime(val) }
>> 
>> 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.
>> https://github.com/apple/swift/blob/8d9ef80304d7b36e13619ea50e6e76f3ec9221ba/stdlib/public/core/LifetimeManager.swift#L45
>> 
>> So why not simply remove the underscore?
> 
> 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".
> 
> 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).

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.)

-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to