[swift-dev] @owned vs @guaranteed convention for 'self' in nonmutating value type methods

[Michael Gottesman]

> On Jan 19, 2016, at 1:32 PM, Michael Gottesman via swift-dev <swift-dev at swift.org> wrote:
> 
>> 
>> On Jan 19, 2016, at 11:53 AM, John McCall via swift-dev <swift-dev at swift.org> wrote:
>> 
>>> On Jan 18, 2016, at 9:28 AM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
>>> For Swift 2, we changed the default reference counting convention for 'self' parameters from +1 "owned" (caller retains, callee releases) to +0 "guaranteed" (caller retains and releases). This makes a lot of sense for class methods, since it's common to invoke a number of methods on the same object in turn. Similarly for value types, it's common to want to perform a bunch of mutations in a row, but we get a "+0"-like convention naturally due to the way 'inout' works. For nonmutating value type operations, it's a bit less clear-cut—a pure operation is more likely to appear once as part of a larger expression. Using +0 also prevents us from reusing self's resources and doing in-place mutation if it's uniquely referenced, which is an extremely useful optimization for a number of operations on strings and containers. We may want to consider whether +1 is a better default, if not for all nonmutating value type methods, maybe some subset where inplace mutation is likely to be profitable. One possible heuristic would be to look at whether a method returns the Self type (possibly including tuples and fragile structs containing Self, or different instantiations of the same Self type).
>> 
>> I feel like the right language solution here is probably just to add attributes to allow methods to opt-in to a different default self convention.
> 
> TBH if we do that I would rather us take this 1 step further and allow any function/method to opt-in to a different calling convention for specific parameters.

Resilience makes this even more important since we can not perform the @owned -> @guaranteed optimization over resilience boundaries.

> 
> Michael
> 
>> 
>> John.
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160119/02ea25fc/attachment.html>