-- Adrian Zubarev Sent with Airmail
Am 30. Juni 2016 um 12:13:10, Adrian Zubarev ([email protected](mailto:[email protected])) 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. > > ```seift > 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 > ([email protected](mailto:[email protected])) schrieb: > > > > > > > > On 29 Jun 2016, at 22:41, David Sweeris via swift-evolution > > > <[email protected](mailto:[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
