> On 29 Jun 2016, at 22:41, David Sweeris via swift-evolution 
> <[email protected]> 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

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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to