I like this proposal in theory. The idea of localizing a member declaration
inside the extension that actually uses that member certainly has advantages.
At the same time, I have concerns about allowing this.
In some ways it makes code less readable because it isn’t possible to see all
of the stored members of a type in one location. IDEs and generated
documentation can help with this, but the code itself suffers.
I am also concerned about how this would interact with initializers, especially
when the member is not provided with an initial value. Adding an extension
that declares a new stored property is likely to have non-local effects. If
you might already need to visit another file to update the initializers when
adding the member the value of allowing the member declaration to be elsewhere
is somewhat reduced.
The initialization concern can at least be mitigated to some degree by
providing an initial value and / or if we adopt the flexible memberwise
initialization proposal and all initializers for the type are able to
initialize the added member using memberwise initialization. That reduces the
concern but doesn’t completely eliminate it.
I think it would be worthwhile to carefully consider how allowing stored
properties in extensions interact with initializers in the wild. Is the value
they provide sufficient to outweigh any initialization complexities they might
introduce? Do we need to include restrictions on stored properties in
extensions in order to reduce those complexities (such as requiring an initial
value)?
Matthew
> On Dec 22, 2015, at 9:40 PM, Jordan Rose via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>>>
>>>> One potentially large downside is you can no longer look at a type
>>>> declaration and find out how large it is. For example, I could define
>>>>
>>>> struct Foo {
>>>> var x: Int
>>>> }
>>>>
>>>> and it looks like a tiny struct, but I could then add an extension in a
>>>> separate file that bloats that out to some ridiculously massive struct,
>>>> and that wouldn't be obvious from looking at it.
>>>
>>> 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.
>>
>> I agree.
>
> I don't see why any reasons that apply to classes wouldn't apply to structs:
> code organization, making the property private, etc. But maybe it should be
> called out explicitly with "@partial" or similar for structs.
>
> Jordan
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
