Do you know why it was never brought to a vote? 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.
> On Jul 8, 2017, at 7:15 PM, Xiaodi Wu <[email protected]> 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 > <[email protected] <mailto:[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] >> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
