<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Fri, Dec 18, 2015, at 05:45 PM, Joe Groff wrote:<br></div>
<blockquote type="cite"><div> </div>
<div><blockquote type="cite"><div>On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<div> </div>
<div><div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote:</span></span><br></div>
<blockquote 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;" type="cite"><blockquote type="cite"><div>On Dec 18, 2015, at 4:19 PM, Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>> wrote:<br></div>
<div>On Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote:<br></div>
<blockquote type="cite">I think any storage-in-extensions proposal ought to be a special feature of classes; I would not support the ability to add stored properties to structs in extensions, even from within the module.<br></blockquote><div> </div>
<div>Oh that's an interesting idea. My immediate reaction to "I don't want unpredictable sizes" was upon reflection something that only applies to structs. Classes are reference types already, so adding storage to them doesn't really have much consequence (structs get copied around so their size is important). Not only that, but we can already use associated objects with classes, so adding proper stored properties to them doesn't actually change the semantics of extensions, it just means avoiding the overhead of associated objects (and of value wrappers for associated objects) when the extension is part of the same module.<br></div>
</blockquote><div> </div>
<div>Right. And I think we’d also want to support some way to explicitly request the out-of-line representation even within the module.<br></div>
</blockquote><div> </div>
<div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Property behaviors could do out-of-line storage for classes (assuming property behaviors retain the ability to get at the owning class, which is something I mentioned as being problematic in my review). You could technically do out-of-line storage for structs by having an inline storage of object type and then using the lifetime of that object to manage the out-of-line storage, but that doesn't seem particularly great and it also breaks value semantics.</span></span><br></div>
</div>
</blockquote></div>
<div> </div>
<div>A behavior should also be able to implement a copy-on-write policy on mutation in order to preserve value semantics in struct containers.<br></div>
</blockquote><div> </div>
<div>I suppose that's true, if a class is used for out-of-line storage then you can use the same uniqueness testing that the existing COW containers use. I was originally thinking about using it like associated objects, but it makes a lot more sense to use something like ManagedBuffer instead.<br></div>
<div> </div>
<div>-Kevin Ballard</div>
<div> </div>
</body>
</html>