[swift-evolution] Proposal - Allow properties in Extensions
kevin at sb.org
Fri Dec 18 19:43:46 CST 2015
On Fri, Dec 18, 2015, at 04:38 PM, John McCall wrote:
> > On Dec 18, 2015, at 4:19 PM, Kevin Ballard <kevin at 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.
More information about the swift-evolution