On Fri, Dec 18, 2015, at 05:45 PM, Joe Groff wrote: > >> On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution <swift- >> evolut...@swift.org> wrote: >> >> On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote: >>>> On Dec 18, 2015, at 4:19 PM, Kevin Ballard <ke...@sb.org> wrote: On >>>> Fri, Dec 18, 2015, at 04:11 PM, John McCall wrote: >>>>> 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. >>>> >>>> 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. >>> >>> Right. And I think we’d also want to support some way to explicitly >>> request the out-of-line representation even within the module. >> >> 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. > > A behavior should also be able to implement a copy-on-write policy on > mutation in order to preserve value semantics in struct containers.
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. -Kevin Ballard
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution