[swift-evolution] Proposal: Enclosed variable in extension scope

[Matthew Johnson]

You are proposing two things:

1. Allow stored properties in extensions.
2. Introduce an access modifier that restricts visibility to the current scope.

I know the first topic has been discussed quite a bit.  I believe some of that discussion has happened on the list.  You should be able to find it by searching the archives.

The second topic has also been discussed quite a bit and a proposal is being developed.  The thread for that topic is "access control proposal”.

Matthew

> On Dec 13, 2015, at 9:19 PM, Nutchaphon Rewik via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Extension is a powerful feature in Swift, allowing type extensibility in various way. However, there are some limitations that everyone has to cope with. We cannot add stored variables to extension scope. ( enclosed variable )
> 
> To workaround with the problem, associated object has been used so far by many Swift/Obj-c library that we are using today. This technique facilitates the power of extension. It allows extension to have enclosed stored property at runtime. However, we can only apply this method to NSObject subclass type. And I think it is some kind of hack, and when it comes to Swift the syntax looks messy.
> 
> So, I would like to propose an idea of storing variable inside extension scope. 'enclose', is a prefix keyword, stating that a variable is only visible inside an extension block scope.
> 
> 
> ​protocol Incrementor{
>     func increase()
>     func otherFunc()
> }
> 
> extension Incrementor{
>     
>     /* 
>         enclose keyword only allow to be used in extension scope
>     */
>     enclose var count = 1 // count is visible only in this extension scope.
>     
>     func increase(){
>         print(count)
>         count = count + 1
>     }
> }
> 
> // another extension scope
> extension Incrementor{
>     
>     // can't see 'count' because it's in another extension scope.
>     func otherFunc(){
>         print("do whatever but you will not see 'count' in this")
>     }
> }
> 
> 
> This allows mixins composition style. It has no side-effect to other parts, and is considered to have better separation of concerns. Since we have protocol extension in Swift 2.0, this feature will empower composition scheme, and eliminates associated object hacking from Swift/Obj-c. 
> 
> Think about rewriting massive view controller as extensions composition. We don't have to store all states of the view controller class in one place. We can separate it to multiple part, each part consists of it own states using enclose keyword.
> 
> I'm pretty sure it will be very useful. So, I would like to ask the opinions of you guys about pros and cons of doing this. What might be an alternative solution? Is it consistent ?
>  _______________________________________________
> 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/20151213/3d2bfc89/attachment.html>