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

Evolution Discussion
1
···

--
Adrian Zubarev
Sent with Airmail

Am 30. Juni 2016 um 12:13:10, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

We could remove the group keyword, but there is a problem with
that. It becomes really strange when you'll try nesting labeled
groups.

public {

labelName {

func member() {}

}

}

It is an interesting suggestion to use extensions that way,
but how would you nest and create diffrent label pathes with
extensions?

We also cannot nest extensions (yet) and when it comes to
conformances the access modier is not allowed on extensions. That
is one of my points to remove this behavior from extensions and
have equal access contol on extensions like on classes etc.!

--

Adrian Zubarev

Sent with Airmail

Am 30. Juni 2016 um
12:04:59, Haravikk (swift-evolution@haravikk.me)
schrieb:

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

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.

2

How about just allowing more periods in the naming? Like so:

  struct A {}
  public extension A.foo {
    func someMethod() { … } // a.foo.someMethod()
  }
  private extension A.foo.bar {
    func someHiddenMethod() { … } // a.foo.bar.someHiddenMethod()
  }

  // Alternatively:
  extension A {
    public func foo.someMethod() { … }
    private func foo.bar.someHiddenMethod() { … }
  }

I suppose it lacks the kind of visual hierarchy that grouping within the type could achieve, but at the same time such grouping could get unwieldy quickly due to implementation details growing the vertical height until the structure becomes unclear. This is why I'd favour extensions personally. There could still be call for both though, as a balance such as simple properties and methods declared hierarchically within the type, vs large methods moved out into extensions, letting us mix and match however we like. I do think that the extension one should be considered though, as it's a recommended way to handle code structure in Swift I think, or at least I'm addicted to using it ;)

···

On 30 Jun 2016, at 11:22, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
It is an interesting suggestion to use extensions that way, but how would you nest and create diffrent label pathes with extensions?

We also cannot nest extensions (yet) and when it comes to conformances the access modier is not allowed on extensions. That is one of my points to remove this behavior from extensions and have equal access contol on extensions like on classes etc.!

3

How about adding attributes on extensions (just bikeshedding), because to me it’s not clear if you’re creating a class/static access label or for an instance of that type?

Nesting extensions would become useful for the sake of access labels.

struct A {
     
    public extension Self.foo {
        func someMethod() { … } // a.foo.someMethod()
    }
     
    private extension Self.foo.bar {
        func someHiddenMethod() { … } // a.foo.bar.someHiddenMethod()
    }
}

// Or
struct A {
     
    public extension self foo {
        func someMethod() { … } // a.foo.someMethod()
    }
     
    private extension self.foo bar {
        func someHiddenMethod() { … } // a.foo.bar.someHiddenMethod()
    }
}
The only problem I have with extensions, that they don’t read that well and personally I don’t like the default access modifier on them (not how its done right now).

Thank you for providing new ideas. :)

···

--
Adrian Zubarev
Sent with Airmail

Am 30. Juni 2016 um 21:57:37, Haravikk (swift-evolution@haravikk.me) schrieb:

struct A {}
public extension A.foo {
func someMethod() { … } // a.foo.someMethod()
}
private extension A.foo.bar {
func someHiddenMethod() { … } // a.foo.bar.someHiddenMethod()
}