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

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to