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

[Xiaodi Wu]

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/20170709/a7f96206/attachment.html>