<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 31, 2016, at 3:25 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I have a proposal for #6 in the pipe, but there are actually some subtleties I have to work out (it's not as simple as just slapping a generic type signature on a let constant).</div></div></blockquote><div><br class=""></div><div>Cool. Looking forward to reviewing a draft when it’s ready.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I think #5 is just considered a 'bug' and doesn't need a proposal (it might actually be finished already; I saw some commits recently); same with #4. #7 is not very useful without variadic generics (it pretty much exists to allow tuples to conform to protocols, and tuples are inherently variadic).</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Good to know 4 and 5 are considered bugs. I know #4 is important for the standard library so I suppose that will ensure it is a priority soon enough.</div><div><br class=""></div><div>I included #7 because it would still be nice to have for a number of reasons. Maybe there is a way to pull it off for a handful of types that are known to the compiler.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I wanted to take a stab at #2. </div></div></div></blockquote><div><br class=""></div><div>Are you still thinking about this one or did you decide not to pursue it?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">The core team has talked so much about #1 that I'd be surprised if they don't already have an idea as to how they want to do it, plus it's complicated for a number of reasons to get right. In such a case having the community push forward an alternate proposal would just be giving everyone more unneeded work.</div></div></div></blockquote><div><br class=""></div><div>Agree here as well. I’ve avoided generics proposals mostly because I thought the core team was leading the charge on all them. It now appears like that may not have been the right assumption across the board. I wish we had a bit more visibility on this...</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">#3 seems semantically straightforward. AFAIK there's nothing a subscript can do that a getter and setter method can't do together, and methods can already be generic. A proposal shouldn't be hard to put together.</div></div></div></blockquote><div><br class=""></div><div>Agree. Someone just needs to jump in and write it up. :-) If it had a chance of making it into Swift 3 I would do it right away, but it’s hard to tell...</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Let me know your thoughts.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 31, 2016 at 1:16 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">This is pretty much where my thinking about the topic has led me as well. I'll resign this topic to pursue some other, hopefully more relevant work, although anyone who wants to continue the discussion is welcome to.</div></div></blockquote><div class=""><br class=""></div></span><div class="">Seems reasonable to wait until we can at least evaluate the macro approach properly.</div><div class=""><br class=""></div><div class="">Are you planning to continue work on generics? FWIW, my top priority list for items without proposals is roughly:</div><div class=""><br class=""></div><div class="">1. Conditional conformance (<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-</a>)</div><div class="">2. Parameterized extensions (<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions</a>)</div><div class="">3. Generic subscripts (<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts</a>)</div><div class="">4. Recursive protocol constraints (<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics</a>)</div><div class="">5. Nested generics (<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics</a>)</div><div class="">6. Default generic arguments (<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments</a>)</div><div class="">7. Extensions of structural types (<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types</a>)</div><div class=""><br class=""></div><div class="">And this one seems like low hanging fruit:</div><div class=""><br class=""></div><div class="">Default implementations in protocols (<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols-" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols-</a>)</div><div class=""><br class=""></div><div class="">How does this compare to your priorities for generics?</div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 31, 2016 at 12:49 PM, Chris Lattner <span dir="ltr" class=""><<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">well there is no macro system, and for the moment a clear statement from chris that this is not on the table in the short term. the code in the example looked like run-of-the-mill swift, except for the “…". so that leaves us with swift looking code that would be executed by the compiler, but with nothing particular to tell which parts to and which not. just a thought.</div></div></div></blockquote><div class=""><br class=""></div></span>Lets be clear though: variadic generics are not in scope for Swift 3 either. </div><div class=""><br class=""></div><div class="">I definitely don’t speak for the rest of the core team, nor have I discussed it with them… but IMO, this whole feature seems like a better fit for a macro system than it does to complicate the generics system. Unlike C++’s template system, our generics system inherently has runtime / dynamic dispatch properties, and I don’t think that shoehorning variadics into it is going to work out well.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Chris</div></font></span><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 31, 2016, at 7:59 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">How so? I'm interested in anything that can get us away from having to generating code at compile-time.<div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic <span dir="ltr" class=""><<a href="mailto:laurent.mihalkovic@gmail.com" target="_blank" class="">laurent.mihalkovic@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><span class=""><div class=""><br class=""></div><div class="">What's interesting about the code in the manifesto is that it looks very much like "..." is a runtime construct, as opposed to trying the get the compiler to do the heavy lifting.<br class=""></div></span></div></blockquote><div class=""><br class=""></div></div></div></div></div>
</div></blockquote></div><br class=""></div></span><span class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>