On Sat, Jul 8, 2017 at 10:52 PM, Jonathan Hull <[email protected]> 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 <[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]> 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
