[swift-evolution] Proposal - Allow properties in Extensions

[Dan Stenmark]

I’d +1 this proposal for extensions existing in the same module as the class declaration.  However, creating new properties for classes defined in other modules would likely involve side-table lookups, and my understanding is that it has some performance implications.  

In cases where you want to extend the storage of a class, consider if maybe a subclass is all you need.

Dan

> On Dec 18, 2015, at 11:42 AM, Nutchaphon Rewik via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I only see the benefits on this.
> We don't have to store all states in one file. States can be stored separately. So, we can write code in more composition style.
> We can add new states to the existing type. Not just NSObject subclass with associated object.
> 
> protocol Incrementer{
>     func increase()
> }
> 
> extension Incrementer{
> 
>     var count = 1 // allows stored properties
>     
>     func increase(){
>         print(count)
>         count = count + 1
>     }
>  
> }
> 
> 
> > On Dec 8, 2015, at 10:51 AM, Kevin Kachikian via swift-evolution <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:
> > 
> > I’d like to proposal to the Swift community and discuss the advantages and disadvantages of adding modifiable properties to extensions (in addition to the already existing computed properties, instance methods, subscripts, etc.):
> > 
> > extension SomeType {
> > 	
> > 	var aNewProperty: Int
> > 	var anotherVariable: String
> > 	var aThirdOne: MyStruct
>  _______________________________________________
> 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/20151218/edf4b6aa/attachment.html>