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

[Karl]

> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Right. The question is whether we *need* to add stored properties out-of-module, and what the use case for that is. To me it seems that adding them in-module is by far the more common use case, for the purposes of implementing protocols.
> 
> At any rate, the rewrite option would be a great addition to Swift regardless of what our answer to the first question is.
> 
> Charles

I actually think out-of-module is the more common and important case. If you’re using a types from an external framework, it’s strange that you can retroactively add functionality but not additional data. That limitation, AFAICT, is purely due to implementation. Some well-constructed frameworks will allow you to add stored data to the types being used by subclassing. Not all are so well constructed, and as we have more and more value-types subclassing is not going to be a solution.

You can add stored properties to objects in Python, which is one of the really great things about it. If you need to add a stored property to track some additional state you layer on top of a framework’s components, it’s staggering how easy it is - you don’t even need to define any new types.

I personally think it’s important for Swift as a scripting language to have this ability - for value-types as well as classes, by default. We could optimise it away completely for types which aren’t public, and you should be able to explicitly declare a type non-extendable (similar to declaring it non-subclassable with ‘final’) to opt-out. I’m sure it will never happen, but there you go.