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

Haravikk swift-evolution at haravikk.me
Thu Jun 30 05:04:59 CDT 2016

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/d4a1d3ad/attachment.html>

More information about the swift-evolution mailing list