[swift-evolution] Proposal - Allow properties in Extensions

[Matthew Johnson]

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 at swift.org> wrote:
> 
> 
>> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution