<div dir="ltr">On Sat, Jul 8, 2017 at 10:52 PM, Jonathan Hull <span dir="ltr">&lt;<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Do you know why it was never brought to a vote?  </div></blockquote><div><br></div><div>If I had to guess, it would be because the core team decided it&#39;s not in scope.</div><div><br></div><div>As an aside not central to your question and not directed to you specifically: There aren&#39;t votes in the evolution process; there are community and core team reviews. The purpose, afaik, isn&#39;t to count the number of replies that say &quot;+1&quot; or &quot;-1.&quot;</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>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.</div></div></blockquote><div><br></div><div> I&#39;m not aware of any proposal text that punts on nested generics.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5"><div><div><blockquote type="cite"><div>On Jul 8, 2017, at 7:15 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_5725758841449547491Apple-interchange-newline"><div>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.<br><br>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.<br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 8, 2017 at 20:59 Jonathan Hull via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br></div><div>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____&quot;.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Jon<br><div><div><div><br></div><div><br><div><blockquote type="cite"><div>On Jul 8, 2017, at 6:10 PM, Akshay Hegde &lt;<a href="mailto:akshay_hegde@me.com" target="_blank">akshay_hegde@me.com</a>&gt; wrote:</div><br class="m_5725758841449547491m_-9067813258815646445Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">Wouldn’t the following work just as well for providing a namespace?<div><br></div><div><span style="font-family:SFMono-Regular;font-size:12px">struct Foozle {</span></div></div></div></blockquote></div></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><br style="font-family:SFMono-Regular;font-size:12px">    <span style="font-family:SFMono-Regular;font-size:12px">enum Errors: Error {</span><br style="font-family:SFMono-Regular;font-size:12px">        <span style="font-family:SFMono-Regular;font-size:12px">case malformedFoozle</span><br style="font-family:SFMono-Regular;font-size:12px">        <span style="font-family:SFMono-Regular;font-size:12px">case tooManyFoozles</span><br style="font-family:SFMono-Regular;font-size:12px">    <span style="font-family:SFMono-Regular;font-size:12px">}</span><br style="font-family:SFMono-Regular;font-size:12px"><font face="SFMono-Regular"><span style="font-size:12px">}</span></font></div></div></div></blockquote></div></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div><div></div></div><div>
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br>~Akshay</div>

</div></div></div></blockquote></div></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space">
<div><br><blockquote type="cite"><div>On Jul 8, 2017, at 17:24, Jonathan Hull via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_5725758841449547491m_-9067813258815646445Apple-interchange-newline"><div><div>I *really* want this as well.<br><br>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.<br><br>Thanks,<br>Jon<br><br><blockquote type="cite">On Jul 8, 2017, at 4:21 PM, William Shipley via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br>Does anyone know if there&#39;s some good tech reason to not allow, like:<br><br>protocol Foozle {<br><span class="m_5725758841449547491m_-9067813258815646445Apple-tab-span" style="white-space:pre-wrap">        </span>enum Errors: Error {<br><span class="m_5725758841449547491m_-9067813258815646445Apple-tab-span" style="white-space:pre-wrap">        </span><span class="m_5725758841449547491m_-9067813258815646445Apple-tab-span" style="white-space:pre-wrap">        </span>case malformedFoozle<br><span class="m_5725758841449547491m_-9067813258815646445Apple-tab-span" style="white-space:pre-wrap">        </span><span class="m_5725758841449547491m_-9067813258815646445Apple-tab-span" style="white-space:pre-wrap">        </span>case tooManyFoozles<br><span class="m_5725758841449547491m_-9067813258815646445Apple-tab-span" style="white-space:pre-wrap">        </span>}<br>}<br><br>Like, to me all this is doing is giving “Errors” a nice namespace, but the compiler might have other thoughts.<br><br>-W<br>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></blockquote><br>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></div></blockquote></div><br></div></div></blockquote></div></div></div></div></div></div>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div>
</div></blockquote></div><br></div></div></div></div></div></blockquote></div><br></div></div>