[swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

[L. Mihalkovic]

-1 looks like a kludgy hack. 
It will force people to have to scroll back to the declaration of a group (with no assistance to find where it is) in order to ascertain the visibility of a given method, while pushing code further to the right for every single method. Couple that with the zealous following of the 80c rules and that makes for a less than stellar coding experience... all in the name of not have to type a modifier.
Regards
(From mobile)

> On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Dear Swift community, as most of you may know we’ve been discussing the future of extintials and diverse design ideas. The result for Swift 3 is a proposal which makes the first step by replacing procotol<A, B> with a new shorthand syntax A & B.
> 
> The reason I’m posting this proposal so early is to get some feedback about this idea in general. If the feedback is positive, I also would like some of you to consider the removal of the access modifier from extensions. By that I don’t mean to remove it completely. My honest opinion is that extensions should have exactly the same access control like classes, enums and structs.
> 
> One take the access control from protocols and mix it with the access control of classes (etc.) and the result is the access control for extensions. I just can’t agree with the fact of laziness of typing out access modifier on extension members some of you might have.
> 
> The current access control on extensions disallow us to use access modifier when we involve protocol conformances.
> 
> Default implementations have three ways of declaring public visibility:
> 
> extension SomeProtocol {
>     public func someMember() {}
> }
>      
> public extension SomeProtocol {
>     func someMember() {}
> }
>      
> public extension SomeProtocol {
>     public func someMember() {}
> }
> If it was the access control mechanism for classes (etc.) there would be only a single correct way to achieve this:
> 
> public class SomeClass {
>     public func someMember() {}
> }
> Feel free to join the conversation about removing the current behavior from extensions for Swift 3. Here is the >>link<< to the last post. (I still have to rewrite a few things to reflect my thoughts from the conversation.)
> 
> I’d like to introduce a new scoped but typeless mechanism to Swift (which might be added after Swift 3 drops). I gave it a clean name group to showcase what it will be used for. You can read my formatted draft >>here<<.
> 
> These were the basic ideas I had. I’ve already seen a few threads where some people were asking for a way organizing variables into groups by an access modifier. So here it is, but a group can solve other problems too. We could finally stop abusing enums and also create access labels for a clear and swifty code design.
> 
> The idea of groups is based on the access control of protocols. It would be great if this mechanism could have its own scope, which then could be used almost anywhere.
> 
> Detailed design
> 
> A group is typeless, and should be used for organization purposes.
> 
> Organizing members by an access modifier.
> 
> Providing an access label to type members (CamelCase).
> 
> Providing namespacing for API design (UpperCamelCase).
> 
> public group Reference {
>     /* implicitly public */ class String { ... }
>     /* implicitly public */ class Char { ... }
> }
> Possible usage:
> 
> let instance = Reference.String()  
> A group can be used inside any scope or at file level.
> 
> A group has one or no label at all:
> 
> A group without a label has always an explicit access modifier:
> 
> public struct A {
>          
>     public group {
>         var a: Int { return self._a }
>         var aTimesTen: Int { return self.a * 10 }
>     }
>              
>     internal group {
>         var _a: Int = 10
>         var _b: Int = 42
>     }
> }
> A group with a label has an optional access modifier:
> 
> Labeled groups without an access modifier are automatically internal.
> Group members have the same access modifier as the group itself (like access modifier on protocols).
> Nested groups inherit the access modifier from its root group.
> Labeled groups cannot be stored in any manner.
> public class UIScrollView : ... {
>          
>     public group {
>      
>         /* implicitly public */ group content {
>             /* implicitly public */ var offset: CGPoint
>             /* implicitly public */ var size: CGSize
>             /* implicitly public */ var inset: UIEdgeInsets
>         }
>                  
>         /* implicitly public */ var someCoolPublicInteger: Int
>     }
>     ...
> }
> Possible usage:
> 
> - scrollViewInstance.contentOffset
> + scrollViewInstance.content.offset
> It should be possible to create multiple groups with the same/different access modfier and the same acess label:
> 
> public struct B {
>      
>     public group labelName {
>         var someVarName: Int
>     }
>          
>     public group labelName {
>         var someOtherVarName: String
>     }
>          
>     internal group labelName {
>         var _internalVarName: Double
>     }
> }
> It should be possible to extend existing labeled groups.
> 
> public struct C {
>      
>     public group labelName {
>         var someVarName: Int
>     }
> }
>      
> public extension C {
>      
>     public group labelName {
>         var computedProperty: Int { ... }
>     }
> }
> Attributes aplied to a group will automatically be aplied to all members.
> 
> public class D {
>      
>     public static group {
>          
>         // public static var
>         var something: Int = 42
>              
>         // public static func
>         func foo() { ... }
>     }
> }
> Grammar
> 
> declaration → group-declaration
> 
> group-declaration → attributesopt access-level-modifier group group-body
> 
> group-declaration → attributesopt access-level-modifieropt group group-name group-body
> 
> group-name → identifier­
> 
> group-body → { declarations }
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/511ba7f7/attachment.html>