<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=""><div><blockquote type="cite" class=""><div class="">On Jan 19, 2016, at 11:04 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 19, 2016, at 10:59 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="" class=""><blockquote type="cite" 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;" class="">On Jan 19, 2016, at 10:34 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">On Jan 19, 2016, at 10:29 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Jan 19, 2016, at 10:05 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">On Jan 19, 2016, at 9:53 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Jan 18, 2016, at 9:28 AM, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class="">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).<br class=""></blockquote><br class="">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.<br class=""></blockquote><br class="">We could do that, but we should still make sure the defaults give the best overall system performance and optimization opportunity.<br class=""></blockquote><br class="">Sure, but we’re talking about very narrow heuristics for changing the defaults here. At most, maybe your Self rule, although there are conspicuous cases (func clone() -> Self) where it would not be appropriate.<br class=""></blockquote><br class="">It's also worth investigating whether it's profitable to apply to all nonmutating value type methods. I think nonmutating 'self' is more likely to be consumed in general than it is for class or mutating methods.<br class=""></blockquote><br 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;" class=""><span 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; float: none; display: inline !important;" class="">Are you imagining, like, a heroic Array.map implementation that applies the transform in-place? Because honestly I think there are very few nonmutating operations that would actually consume self.</span><br 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;" class=""></div></div></blockquote></div><br class=""><div class="">Almost every operation with an efficient in-place form for uniquely-referenced mutation could also use that in-place variant for nonmutating operations—nonmutating variants of appending, removing, uppercaseString, etc. could all benefit.</div></div></div></blockquote><div><br class=""></div></div>1. Many of the in-place proposals have discussed having special optimization rules for turning functional-style operations to in-place ones. I don’t know where those stand, but it’s something I think we’d want to pursue directly.<div class=""><br class=""></div><div class="">2. I don’t think those operations dominate the set of all nonmutating operations on value types.</div><div class=""><br class=""></div><div class="">John.</div></body></html>