[swift-evolution] [Pre-pitch] Allowing enums inside protocols?

[Xiaodi Wu]

On Sat, Jul 8, 2017 at 10:52 PM, Jonathan Hull <jhull at gbis.com> wrote:

> Do you know why it was never brought to a vote?
>

If I had to guess, it would be because the core team decided it's not in
scope.

As an aside not central to your question and not directed to you
specifically: There aren't votes in the evolution process; there are
community and core team reviews. The purpose, afaik, isn't to count the
number of replies that say "+1" or "-1."


> I seem to remember us having a pretty good consensus.  I think we decided
> to punt on nested generics by just not allowing nesting in them yet (which
> would be compatible since that is what happens now too).  Then we would
> have a second proposal to deal with generics/associated more carefully.
>

 I'm not aware of any proposal text that punts on nested generics.

On Jul 8, 2017, at 7:15 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> At least one fairly complete draft for allowing concrete types to be
> declared inside protocols was at some point a PR in the swift-evolution
> repo. Worth taking a look at.
>
> The chief source of complexity is in terms of how to refer to or capture
> types or members of the containing type or protocol. In the draft I
> remember, protocols could be nested inside types, and types could be nested
> inside protocols. Whether and how a protocol with associated type
> requirements inside a generic type inside another protocol with associated
> type requirements can refer to types or members of the outermost protocol
> gets quickly very convoluted; this requires careful design.
>
> On Sat, Jul 8, 2017 at 20:59 Jonathan Hull via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> The idea (at least for me) is to namespace the enum within the protocol,
>> so that users of the protocol have everything neatly packaged.  Right now I
>> have to make a Separate “FoozleErrors” enum, which just feels messy.
>>
>> I would really like to see us be able to nest Structs, Enums, and even
>> other Protocols within a protocol, and it would just act as a namespace.
>> Wil is right though, that if we can only have one, Enums give us the most
>> bang for our buck.  That is the case I run into most often.  In addition to
>> Error Enums, I also have a lot of places where protocol functions return a
>> classification (as an enum), and it is cluttering the top-level namespace
>> with things named “Foozle____".
>>
>> It isn’t a huge issue (it doesn’t stop me from doing anything), but it is
>> an annoyance that I run into all the time…  I view the fact that Swift
>> doesn’t support this as a bug.
>>
>> Thanks,
>> Jon
>>
>>
>> On Jul 8, 2017, at 6:10 PM, Akshay Hegde <akshay_hegde at me.com> wrote:
>>
>> Wouldn’t the following work just as well for providing a namespace?
>>
>> struct Foozle {
>>
>>
>>     enum Errors: Error {
>>         case malformedFoozle
>>         case tooManyFoozles
>>     }
>> }
>>
>>
>> ~Akshay
>>
>>
>> On Jul 8, 2017, at 17:24, Jonathan Hull via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I *really* want this as well.
>>
>> I think there was a serious proposal to do this early in Swift 4.  Not
>> sure why it stalled, but I seem to remember it being technically possible.
>>
>> Thanks,
>> Jon
>>
>> On Jul 8, 2017, at 4:21 PM, William Shipley via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Does anyone know if there's some good tech reason to not allow, like:
>>
>> protocol Foozle {
>> enum Errors: Error {
>> case malformedFoozle
>> case tooManyFoozles
>> }
>> }
>>
>> Like, to me all this is doing is giving “Errors” a nice namespace, but
>> the compiler might have other thoughts.
>>
>> -W
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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/20170708/f20358a8/attachment.html>