Sent from my iPad
> On Jun 30, 2016, at 5:10 AM, Haravikk via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On 30 Jun 2016, at 11:04, Haravikk via swift-evolution >> <swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution