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

[Jonathan Hull]

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 <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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/bf41ee08/attachment.html>