[swift-evolution] Improved value and move semantics

[Joe Groff]

> On Aug 3, 2016, at 8:46 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Aug 3, 2016, at 7:57 PM, Joe Groff <jgroff at apple.com> wrote:
>>>>> 
>>>>> a. We indirect automatically based on some heuristic, as an
>>>>> optimization.
>>> 
>>> I weakly disagree with this, because it is important that we provide a predictable model.  I’d rather the user get what they write, and tell people to write ‘indirect’ as a performance tuning option.  “Too magic” is bad.
>> 
>> I think 'indirect' structs with a heuristic default are important to the way people are writing Swift in practice. We've seen many users fully invest in value semantics types, because they wants the benefits of isolated state, without appreciating the code size and performance impacts. Furthermore, implementing 'indirect' by hand is a lot of boilerplate. Putting indirectness entirely in users' hands feels to me a lot like the "value if word sized, const& if struct" heuristics C++ makes you internalize, since there are similar heuristics where 'indirect' is almost always a win in Swift too.
> 
> I understand with much of your motivation, but I still disagree with your conclusion.  I see this as exactly analogous to the situation and discussion when we added indirect to enums.  At the time, some argued for a magic model where the compiler figured out what to do in the most common “obvious” cases.  
> 
> We agreed to use our current model though because:
> 1) Better to be explicit about allocations & indirection that implicit.  
> 2) The compiler can guide the user in the “obvious” case to add the keyword with a fixit, preserving the discoverability / ease of use.
> 3) When indirection is necessary, there are choices to make about where the best place to do it is.
> 4) In the most common case, the “boilerplate” is a single “indirect” keyword added to the enum decl itself.  In the less common case, you want the “boilerplate” so that you know where the indirections are happening.
> 
> Overall, I think this model has worked well for enums and I’m still very happy with it.  If you generalize it to structs, you also have to consider that this should be part of a larger model that includes better support for COW.  I think it would be really unfortunate to “magically indirect” struct, when the right answer may actually be to COW them instead.  I’d rather have a model where someone can use:
> 
> // simple, predictable, always inline, slow in some cases.
> struct S1 { … }  
> 
> And then upgrade to one of:
> 
> indirect struct S2 {…}
> cow struct S3 { … } 
> 
> Depending on the structure of their data.  In any case, to reiterate, this really isn’t the time to have this debate, since it is clearly outside of stage 1.

In my mind, indirect *is* cow. An indirect struct without value semantics is a class, so there would be no reason to implement 'indirect' for structs without providing copy-on-write behavior. I believe that the situation with structs and enums is also different. Indirecting enums has a bigger impact on interface because they enable recursive data structures, and while there are places where indirecting a struct may make new recursion possible, that's much rarer of a reason to introduce indirectness for structs. Performance and code size are the more common reasons, and we've described how to build COW boxes manually to work around performance problems at the last two years' WWDC. There are pretty good heuristics for when indirection almost always beats inline storage: once you have more than one refcounted field, passing around a box and retaining once becomes cheaper than retaining the fields individually. Once you exceed the fixed-sized buffer threshold of three words, indirecting some or all of your fields becomes necessary to avoid falling off a cliff in unspecialized generic or protocol-type-based code. Considering that we hope to explore other layout optimizations, such as automatically reordering fields to minimize padding, and that, as with padding, there are simple rules for indirecting that can be mechanically followed to get good results in the 99% case, it seems perfectly reasonable to me to automate this.

-Joe