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

[Brandon Knope]

I also floated this idea awhile back too: http://article.gmane.org/gmane.comp.lang.swift.evolution/17289

Obviously this kind of thing is out of scope for Swift 3

Brandon 

Sent from my iPad

> On Jun 30, 2016, at 8:14 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Jun 30, 2016, at 5:10 AM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 30 Jun 2016, at 11:04, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 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.
>> 
>> Sorry for the immediate followup, but somehow I forgot that we can already have access modifiers on extensions for setting the default, so really all that's needed to meet the remaining needs of the proposal seems to be named extensions. I seem to recall a proposal for this may already exist but can't find it, anyone remember and have a link handy?
> 
> There is no specific proposal for naming extensions because there is nothing gained by just giving them a name.  However, named extensions have been discussed in the context of other features such as allowing extensions to have stored properties.  This is discussed in the appendix of the partial initializer proposal I started but tabled until after Swift 3: https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md.  You can find some discussion in the list archive during the early to mid January timeframe. 
> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/7a974aa1/attachment.html>