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 < [email protected]> 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 <[email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 > [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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
