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