> 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