[swift-evolution] Proposal - Allow properties in Extensions

[Kevin Ballard]

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-
>> 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/7dcf2591/attachment.html>