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

[Adrian Zubarev]

--  
Adrian Zubarev
Sent with Airmail  

Am 30. Juni 2016 um 12:13:10, Adrian Zubarev (adrian.zubarev at devandartist.com(mailto:adrian.zubarev at 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.  
>  
> ```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 (swift-evolution at haravikk.me(mailto:swift-evolution at haravikk.me)) schrieb:
>  
> >  
> >  
> > > On 29 Jun 2016, at 22:41, David Sweeris via swift-evolution <swift-evolution at swift.org(mailto: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/795e9317/attachment.html>