[Post Swift 3] [Proposal] Introducing `group` mechanism


(Adrian Zubarev) #1

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


(Charlie Monroe) #2

A similar proposal can be found here:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html

It uses a bit different syntax, but the gist of it seems the same to me...

···

On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution <swift-evolution@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<< <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022511.html> 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<< <https://gist.github.com/DevAndArtist/c74f706febf93452999881335f6ca1f9>.

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(L Mihalkovic) #3

-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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #4

This is one of the posts I was referring to, thanks for providing the link. I enhanced the idea to solve more problems with a single mechanism.

···

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 17:39:05, Charlie Monroe (charlie@charliemonroe.net) schrieb:

A similar proposal can be found here:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html

It uses a bit different syntax, but the gist of it seems the same to me...

On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #5

Am I understanding your feedback right that you’re in favor of this:

public class func member1() {}
public class func member2() {}
public class func member3() {}
public class func member4() {}
public class func member5() {}
Instead of:

public class group {

    func member1() {}
    func member2() {}
    func member3() {}
    func member4() {}
    func member5() {}
}
And you’re argument is ‘scrolling back’?

If so, I’d think that you’re logic would also apply to the default access modifier on extensions.

···

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 19:35:35, L. Mihalkovic (laurent.mihalkovic@gmail.com) schrieb:

-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


(Adrian Zubarev) #6

Looking at how c++ has a similar access modifier indent mechanism I’m still wondering if you’d argue about scrolling there.

with no assistance to find where it is
An assistant isn’t something the language solves for you. This is a different talk about the IDE. Grab some stdlib or foundation code and look at the filename and the code inside the file. The file might not contain only a single type equal to the filename. Also if there is another huge type present and you have a small display and currently looking at some specific member in the middle of that that type, which assistance have to find out the type of that member? Here we go again: you’re own assistant will your own negative argument ‘scrolling’.

···

--
Adrian Zubarev
Sent with Airmail


(David Sweeris) #7

Speaking of C++, is the “group” keyword even necessary? To borrow your own example from earlier, it seems like we could just as easily say this:
public struct A {
    public { // all public
        func member1() {}
        func member2() {}
        func member3() {}
    }
    public labelName {// all public, accessible under `foo.lableName`
        func member4() {}
        func member5() {}
        func member6() {}
    }
}
(which is not C++’s syntax, I know… the comment just got me thinking about it is all)

- Dave Sweeris

···

On Jun 29, 2016, at 1:03 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Looking at how c++ has a similar access modifier indent mechanism I’m still wondering if you’d argue about scrolling there.

with no assistance to find where it is
An assistant isn’t something the language solves for you. This is a different talk about the IDE. Grab some stdlib or foundation code and look at the filename and the code inside the file. The file might not contain only a single type equal to the filename. Also if there is another huge type present and you have a small display and currently looking at some specific member in the middle of that that type, which assistance have to find out the type of that member? Here we go again: you’re own assistant will your own negative argument ‘scrolling’.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #8

Thats not true, this isn’t another extension. First of all a group is typeless and can be used for sugaring your code design. Access labels are optional but can be used in two ways: 1) Namespaces or 2) as a bottleneck label (scrollView.content.size).

If you’re using a labeled group you’re forced to use the label to access its typed members.

group is for organizing, reducing attributes and access modifier boiler plate without the need for creating a real new type.

An extension cannot organize something by access modifier without an actual type.

public struct A {
     
    public group {
         
        // all public
        func member1() {}
        func member2() {}
        func member3() {}
    }
     
    public group labelName {
        func member4() {}
        func member5() {}
        func member6() {}
    }
}

let a = A()
a.member1()
a.labelName.member4()

···

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 19:07:17, David Hart (david@hartbit.com) schrieb:

I still have difficulties seeing an appeal in the proposal as it seems to be created new syntax to describe something that extensions can already do. Why use two concepts when one is enough?

On 29 Jun 2016, at 17:43, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

This is one of the posts I was referring to, thanks for providing the link. I enhanced the idea to solve more problems with a single mechanism.

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 17:39:05, Charlie Monroe (charlie@charliemonroe.net) schrieb:

A similar proposal can be found here:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html

It uses a bit different syntax, but the gist of it seems the same to me...

On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #9

I can’t resist I’ve got a third argument for your ‘scrolling’: Grab a huge protocol that does not fit on your screen, which assistance do you have to get its access modifier?

···

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 20:03:31, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Looking at how c++ has a similar access modifier indent mechanism I’m still wondering if you’d argue about scrolling there.

with no assistance to find where it is
An assistant isn’t something the language solves for you. This is a different talk about the IDE. Grab some stdlib or foundation code and look at the filename and the code inside the file. The file might not contain only a single type equal to the filename. Also if there is another huge type present and you have a small display and currently looking at some specific member in the middle of that that type, which assistance have to find out the type of that member? Here we go again: you’re own assistant will your own negative argument ‘scrolling’.

--
Adrian Zubarev
Sent with Airmail


(L Mihalkovic) #10

Regards
(From mobile)

Am I understanding your feedback right that you’re in favor of this:

public class func member1() {}
public class func member2() {}
public class func member3() {}
public class func member4() {}
public class func member5() {}
Instead of:

public class group {

    func member1() {}
    func member2() {}
    func member3() {}
    func member4() {}
    func member5() {}
}
And you’re argument is ‘scrolling back’?

No sure i understand your point here. The problem i see with this proposal is that what may look quaint with empty methods in an email will turn into a practicality nightmare with real code. If I recall, there was even a past argument from a core team member (chris?) about something different but alluding to a very similar lack-of-practicality-at-scale.

···

On Jun 29, 2016, at 7:43 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Am 29. Juni 2016 um 19:35:35, L. Mihalkovic (laurent.mihalkovic@gmail.com) schrieb:

-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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(L Mihalkovic) #11

Comparing with c++ is interesting... Do you remember that when u look at the implementation, the modifier is on every single method, so that when looking at a single page of code u do not have to go far to be reminded of the signature of what you are modifying... additionally, because the impl is separate, the code does not have to float 2 tabs away fromthe left margin (not to mention that in c++ we tend to favor 2 spaces indentations). Altogether the c++ has a more viable set of compromises than this proposal offers.
Regards
(From mobile)

···

On Jun 29, 2016, at 11:41 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

Speaking of C++, is the “group” keyword even necessary? To borrow your own example from earlier, it seems like we could just as easily say this:
public struct A {
    public { // all public
        func member1() {}
        func member2() {}
        func member3() {}
    }
    public labelName {// all public, accessible under `foo.lableName`
        func member4() {}
        func member5() {}
        func member6() {}
    }
}
(which is not C++’s syntax, I know… the comment just got me thinking about it is all)

- Dave Sweeris

On Jun 29, 2016, at 1:03 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Looking at how c++ has a similar access modifier indent mechanism I’m still wondering if you’d argue about scrolling there.

with no assistance to find where it is
An assistant isn’t something the language solves for you. This is a different talk about the IDE. Grab some stdlib or foundation code and look at the filename and the code inside the file. The file might not contain only a single type equal to the filename. Also if there is another huge type present and you have a small display and currently looking at some specific member in the middle of that that type, which assistance have to find out the type of that member? Here we go again: you’re own assistant will your own negative argument ‘scrolling’.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Haravikk) #12

This form is interesting, but personally when it comes to grouping I've become a huge fan of using focused extensions, meaning my type declarations are usually nothing but the bare minimum definition for stored properties and required constructors, everything else goes into the most relevant extension.

As such it seems to me like this feature request could be handled by two features; named extensions, and access modifiers on extensions, so I could do something like so:

  public struct A { … }

  // My awesome labelName implementation
  public extension A.labelName {
    func member4() { … }
    func member5() { … }
    func member6() { … }
  }

Here the public modifier changes the default for functions without a modifier of their own, purely for convenience (as they can still be overridden if I need a private method to implement them) and the label lets me organise them under the parent type. Multiple such extensions could be specified for the same label, with their own default access and/or type constraints.

So yeah, grouping is handy, but I think that extensions already provide a good way to achieve this, and it would make more sense to focus any additions onto them.

···

On 29 Jun 2016, at 22:41, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

Speaking of C++, is the “group” keyword even necessary? To borrow your own example from earlier, it seems like we could just as easily say this:
public struct A {
    public { // all public
        func member1() {}
        func member2() {}
        func member3() {}
    }
    public labelName {// all public, accessible under `foo.lableName`
        func member4() {}
        func member5() {}
        func member6() {}
    }
}
(which is not C++’s syntax, I know… the comment just got me thinking about it is all)

- Dave Sweeris


(Xiaodi Wu) #13

-1 from me as well. As mentioned before, submodules will require their own
extensive discussion and is another matter entirely from grouping access
modifiers. These two topics don't really share anything in common other
than that they are units of code. I have a hard time subscribing to the
idea that an issue as broad as submodules should be solved with a syntax
that simply means "this is an arbitrary unit of code".

···

On Wed, Jun 29, 2016 at 1:16 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

I can’t resist I’ve got a third argument for your ‘scrolling’: Grab a huge
protocol that does not fit on your screen, which assistance do you have to
get its access modifier?

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 20:03:31, Adrian Zubarev (
adrian.zubarev@devandartist.com) schrieb:

Looking at how c++ has a similar access modifier indent mechanism I’m
still wondering if you’d argue about scrolling there.

with no assistance to find where it is

An assistant isn’t something the language solves for you. This is a
different talk about the IDE. Grab some stdlib or foundation code and look
at the filename and the code inside the file. The file might not contain
only a single type equal to the filename. Also if there is another huge
type present and you have a small display and currently looking at some
specific member in the middle of that that type, which assistance have to
find out the type of that member? Here we go again: you’re own assistant
will your own negative argument ‘scrolling’.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #14

Just an extra comment I’d want to add:

Swift isn’t a language that should have only a single concept how you solve a problem.
You can still use closed enums for namespaces, but it feels not right. There is no other (better) solution yet, so we’re indeed using enums at the moment.
In Swift 3 we don’t have c for loops anymore, so how do we iterate backwards now? There are different solutions, and no one is arguing that we should only have one for that.
We have API design guidelines, but no one would force you to even read it, and your code design is up to you.
A group introduces a new purely additive scoped syntax for organizing code.

···

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 19:28:24, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Thats not true, this isn’t another extension. First of all a group is typeless and can be used for sugaring your code design. Access labels are optional but can be used in two ways: 1) Namespaces or 2) as a bottleneck label (scrollView.content.size).

If you’re using a labeled group you’re forced to use the label to access its typed members.

group is for organizing, reducing attributes and access modifier boiler plate without the need for creating a real new type.

An extension cannot organize something by access modifier without an actual type.

public struct A {
      
    public group {
          
        // all public
        func member1() {}
        func member2() {}
        func member3() {}
    }
      
    public group labelName {
        func member4() {}
        func member5() {}
        func member6() {}
    }
}

let a = A()
a.member1()
a.labelName.member4()

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 19:07:17, David Hart (david@hartbit.com) schrieb:

I still have difficulties seeing an appeal in the proposal as it seems to be created new syntax to describe something that extensions can already do. Why use two concepts when one is enough?

On 29 Jun 2016, at 17:43, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

This is one of the posts I was referring to, thanks for providing the link. I enhanced the idea to solve more problems with a single mechanism.

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 17:39:05, Charlie Monroe (charlie@charliemonroe.net) schrieb:

A similar proposal can be found here:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html

It uses a bit different syntax, but the gist of it seems the same to me...

On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(L Mihalkovic) #15

Regards
(From mobile)

I can’t resist I’ve got a third argument for your ‘scrolling’: Grab a huge protocol that does not fit on your screen, which assistance do you have to get its access modifier?

Is this argument a translation for "look, the problem already exists, so it should really not matter that we make it worse"?

···

On Jun 29, 2016, at 8:16 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 20:03:31, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Looking at how c++ has a similar access modifier indent mechanism I’m still wondering if you’d argue about scrolling there.

with no assistance to find where it is
An assistant isn’t something the language solves for you. This is a different talk about the IDE. Grab some stdlib or foundation code and look at the filename and the code inside the file. The file might not contain only a single type equal to the filename. Also if there is another huge type present and you have a small display and currently looking at some specific member in the middle of that that type, which assistance have to find out the type of that member? Here we go again: you’re own assistant will your own negative argument ‘scrolling’.

--
Adrian Zubarev
Sent with Airmail

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #16

+1 what an argument! This doesn’t help here in any way.

If you think there must be a solution for the problem you mentioned in your first reply here, feel free to propose for no more implicit access modifier.

···

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 20:24:26, L. Mihalkovic (laurent.mihalkovic@gmail.com) schrieb:

If I recall, there was even a past argument from a core team member (chris?) about something different but alluding to a very similar lack-of-practicality-at-scale.


(Haravikk) #17

Sorry for the immediate followup, but somehow I forgot that we can already have access modifiers on extensions for setting the default, so really all that's needed to meet the remaining needs of the proposal seems to be named extensions. I seem to recall a proposal for this may already exist but can't find it, anyone remember and have a link handy?

···

On 30 Jun 2016, at 11:04, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

This form is interesting, but personally when it comes to grouping I've become a huge fan of using focused extensions, meaning my type declarations are usually nothing but the bare minimum definition for stored properties and required constructors, everything else goes into the most relevant extension.

As such it seems to me like this feature request could be handled by two features; named extensions, and access modifiers on extensions, so I could do something like so:

  public struct A { … }

  // My awesome labelName implementation
  public extension A.labelName {
    func member4() { … }
    func member5() { … }
    func member6() { … }
  }

Here the public modifier changes the default for functions without a modifier of their own, purely for convenience (as they can still be overridden if I need a private method to implement them) and the label lets me organise them under the parent type. Multiple such extensions could be specified for the same label, with their own default access and/or type constraints.

So yeah, grouping is handy, but I think that extensions already provide a good way to achieve this, and it would make more sense to focus any additions onto them.


(Adrian Zubarev) #18

How is this worse? Your argument about scrolling is just ridiculous. I can repeat myself but this time you could look a some current extension without any conformances. If all members don’t override the default access modifier you’ll end up in the same situation. Your argument is about the lack of an assistant to see some information about a member, which is indeed not present in the model of a group, but it also isn’t in protocols and in some extensions.

···

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 20:32:01, L. Mihalkovic (laurent.mihalkovic@gmail.com) schrieb:

Is this argument a translation for "look, the problem already exists, so it should really not matter that we make it worse"?


(Chéyo Jiménez) #19

You are being apprehensive about this. We all want grouping of access modifiers just like c++ has but what you are proposing doesn't seem to be a clear win. In fact I would much rather have plain c++ groupings than group{}.

Could you also "replay all" not just the evolution list? It makes it hard to follow threads.

-1 from me as well, sorry. You should bring this additive change up again for discussion in August though.

···

On Jun 29, 2016, at 11:43 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

+1 what an argument! This doesn’t help here in any way.

If you think there must be a solution for the problem you mentioned in your first reply here, feel free to propose for no more implicit access modifier.

--
Adrian Zubarev
Sent with Airmail

Am 29. Juni 2016 um 20:24:26, L. Mihalkovic (laurent.mihalkovic@gmail.com) schrieb:

If I recall, there was even a past argument from a core team member (chris?) about something different but alluding to a very similar lack-of-practicality-at-scale.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #20

This form is interesting, but personally when it comes to grouping I've become a huge fan of using focused extensions, meaning my type declarations are usually nothing but the bare minimum definition for stored properties and required constructors, everything else goes into the most relevant extension.

As such it seems to me like this feature request could be handled by two features; named extensions, and access modifiers on extensions, so I could do something like so:

  public struct A { … }

  // My awesome labelName implementation
  public extension A.labelName {
    func member4() { … }
    func member5() { … }
    func member6() { … }
  }

Here the public modifier changes the default for functions without a modifier of their own, purely for convenience (as they can still be overridden if I need a private method to implement them) and the label lets me organise them under the parent type. Multiple such extensions could be specified for the same label, with their own default access and/or type constraints.

So yeah, grouping is handy, but I think that extensions already provide a good way to achieve this, and it would make more sense to focus any additions onto them.

Sorry for the immediate followup, but somehow I forgot that we can already have access modifiers on extensions for setting the default, so really all that's needed to meet the remaining needs of the proposal seems to be named extensions. I seem to recall a proposal for this may already exist but can't find it, anyone remember and have a link handy?

There is no specific proposal for naming extensions because there is nothing gained by just giving them a name. However, named extensions have been discussed in the context of other features such as allowing extensions to have stored properties. This is discussed in the appendix of the partial initializer proposal I started but tabled until after Swift 3: https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md. You can find some discussion in the list archive during the early to mid January timeframe.

···

Sent from my iPad

On Jun 30, 2016, at 5:10 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 30 Jun 2016, at 11:04, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution