[swift-evolution] stored properties in extensions (was: associated objects)

[Paul Cantrell]

This line of thought suggests that allowing stored properties for same-module extensions is not only much more feasible to implement, but also makes more sense at the user level.

> On Nov 10, 2016, at 4:36 AM, Jay Abbott <jay at abbott.me.uk> wrote:
> 
> Perhaps some types don’t lend themselves to being extended?
> 
> Intuitively I would think any extensions should not affect the core behaviour at all. So if I extended a type by adding a property x, two instances with everything else the same and different values of x should still be considered equal by a type-specific equality check. For example you would agree that 1 + 1 = 2 but what if the numbers were coloured red, blue, and yellow respectively, like fridge-magnets, should 1(red) + 1(blue) = 2(yellow)? I think yes. The colour is an extension, it doesn’t change the fundamental concept or behaviour of an integer number.
> 
> I see extensions as a way to add functionality (and potentially data), but without affecting the core behaviour. If you wanted to change behaviour then you should use inheritance or composition to create something new. You can’t then use your own type for instances created by a library, unless it gives you a way to do that, the library would expect its own types to behave in a predictable way, similarly they should behave the same way when extended.
> 
> 
> On Thu, 3 Nov 2016 at 15:14 Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Has anybody thought about the semantic issues of out-of-module extensions with stored properties apart from the implementation issues?
> 
> Such properties could potentially wreak havoc with the semantics of the type being extended. How would these properties play nice with an existing definition of equality, for example? How can it be guaranteed that their value is consistent with the remaining state? And kept that way in case of mutability?
> 
> -Thorsten
> 
> > Am 15.10.2016 um 03:01 schrieb Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
> >
> >
> >> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>
> >> Let extensions introduce stored properties, but only in the same module as the type’s definition. Then, the compiler can just take any extensions into consideration when it’s determining the size of the type, just as if the properties had been declared in the type. Declaring stored properties on an extension outside of the type’s module results in a compiler error, exactly as today. This would, without any performance drawbacks, solve one of the big problems that people are hoping to solve via stored properties in extensions—the ability to organize members by protocol conformance.
> >
> > Yes please! A big strong +1 to this from me. I can think of several specific chunks of problem code that this would clean up immensely.
> >
> > Contra Karl in another message, it’s _in-module_ stored property extensions that I want most frequently. By far.
> >
> > It seems to me that Charles’s idea could be introduced as its own proposal. If out-of-module stored property extensions do eventually become feasible, then Charles’s proposal is a good stepping stone. If they never do, then his proposal has done no harm.
> >
> > I realize this probably falls into the post-ABI stability bucket, but I’d love to help write/support the proposal when its time comes.
> >
> > Cheers,
> >
> > Paul
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161110/440a83b4/attachment.html>