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

[Michael Gottesman]

> On Jan 18, 2016, at 11: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.

I guess you are implying here that we would be forwarding along self in the complicated computation? Wouldn't we at most have one retain/release for the expression on the value due to SILGen peepholes/SGFContexts (maybe my memory is wrong)?

> Using +0 also prevents us from reusing self's resources

Can you elaborate?

> and doing in-place mutation if it's uniquely referenced

I thought we were talking about non-mutating value type methods? (I am confused). Can you elaborate here?

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

We need to be very careful here. We saw large reductions in the number of dynamic retains/releases at -Onone and significant improvements at -O across many benchmarks.

> 
> -Joe
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev