<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 Dec 10, 2015, at 4:14 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">+1 to this. I would really like to see what is and isn't in scope for Swift 3's generics system. Among other things, it would help focus the community's proposals and ideas for the evolution of the type system. An example, people have expressed interest in HKTs, and perhaps a discussion can be opened on how Swift 3's type system can lay the foundation for further changes.<div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Off the top of my head, the following are not currently supported and are requirements for any kind of ‘complete’ generics system:</div><div><br class=""></div><div>- Generic types nested inside generic functions</div><div>- Generic types nested inside generic types</div><div>- Generic functions nested inside generic functions which capture values or outer generic types</div><div><br class=""></div><div>All of these would be easier once we rip out PolymorphicFunctionType and GenericParamList in favor of consistently using GenericFunctionType and GenericSignature everywhere. This is what Sema’s “getType()” vs “getInterfaceType()” business on ValueDecls is all about. Once the old “contextual” types are gone, some tricky parallel code paths for building up the two representations of generic function signatures will be much simpler and more robust, and the missing functionality added easier. This is blocked on a number of architectural changes, for example SIL type lowering has to be able to associate a GenericTypeParamType with the GenericSignature that contains it, and right now it can’t really do that except for one distinguished GenericSignature, which forces us to use non-interface types when forming calls and such.</div><div><br class=""></div><div>A large number of compiler_crashers are instances of the above three unsupported constructs which trip Sema bugs — even though we have diagnostics that catch most of these, the fact that the type checker doesn’t just stop after diagnosing once means that internal inconsistencies resulting an incomplete implementation of generics can trigger assertions down the road.</div><div><br class=""></div><div>Slava</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 10, 2015 at 3:45 PM, Matthew Johnson via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</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="">One of the stated focus areas for Swift 3 is to complete the generics system. <div class=""><br class=""></div><div class="">How far along is the design for the “complete” generics system? Is there appetite among the core team to involve the community in evaluating planned features or submitting proposals to complement existing plans?</div><div class=""><br class=""></div><div class="">Also, is there any documentation other than <a href="https://github.com/apple/swift/blob/master/docs/Generics.rst" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/Generics.rst</a> describing in detail what the complete vision for the generics system is and what new features will be added in Swift 3 (as well as any generics features that have been decided against for Swift or version 3 specifically)?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Matthew</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=7XtDdMHRjqIUi4tzSjSp2pWQIyxYdP6woIWn4vwV5gfTZJeZUEpd-2FYUeFTgVjUzsvrqr2HWwbkhbh7EvJcmNODMxzYF-2F-2FZjcvlqEbf8ZAMF4N1vfi8WopGa1y08ZF-2FTzEFHKkWQpeGOVjvMT-2FrABu5chf-2BDd9Wf2KOJENgX4fVMSjwdXd6rbO3-2FLsvLTZFq2gHmYhUpgPThYhpfXH1pvZ76alZcSUel48ZQw8oYhHiY-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
</div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=NLTid1W7V2mxBEfr5Y3KfTntaxSmOQp5vjACZc9Eh1-2FKAsN5iDGlfNx5NgubBSCFvv8HjpMOZ3pP54J5My30Clv0Ni70rHs2NRnH-2BeFad7YfrHL8L9byUlVBxW5lNNO2DuPaLiyQjo6UqXd5-2BjsH3S7dkz1n5njuagH4kKaDjkpurNQUXtBoyzrJ7TpSVwtcsw1GF-2FpR-2Fu8t8gn-2BafyMLH3vHRhpd2UjOU1x05xuiT4-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>