> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution 
> <swift-evolution@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.
swift-evolution mailing list

Reply via email to