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
