[swift-evolution] Proposal - Allow properties in Extensions

[Joe Groff]

> On Dec 18, 2015, at 5:43 PM, Kevin Ballard via swift-evolution <swift-evolution at 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 <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.

A behavior should also be able to implement a copy-on-write policy on mutation in order to preserve value semantics in struct containers.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/d78f629d/attachment.html>