> 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