<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="">No feedback at all?<div class=""><br class=""></div><div class="">-David Waite</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 3:50 PM, David Waite 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2016, at 11:40 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jan 4, 2016, at 10:30 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Interesting. I was under the impression the core team was taking on the generics features.<span class="Apple-converted-space"> </span></div></div></blockquote><div class=""><br class=""></div><div class="">We are, and lots of them. I doubt we can handle another.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> I am also very interested in helping to accelerate the process if that is possible (whether that means Swift 3 or not).</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Are you thinking specifically about unbound existentials like in your Equatable example or also partly / fully bound existentials such as SequenceType<Generator.Element == Int>?</div></div></blockquote><div class=""><br class=""></div><div class="">I was thinking mostly about the former. However, the latter is also a highly-requested feature [*] that complements this one, and I think it’s reasonable to discuss both together.</div><div class=""><br class=""></div><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">[*] And is often the underlying reason why developers ask for parameterized protocols.</div></div></blockquote><div class=""><br class=""></div>Resurrecting this conversation, I’ve been working on a proposal to (I believe) cover all these points. I’ve decided it is probably better to resurrect this conversation first in order to start having discussion about the features in general, rather than my specific proposal.</div><div class=""><br class=""></div><div class="">Specifically I am seeking to define:</div><div class="">1. The ability for protocols with Self or associated type constraints to be used other than as generic constraints on concrete types (i.e. as existential types)</div><div class="">2. The ability to use said protocols with none, some, or all of the associated types being constrained/bound.</div><div class="">3. Rules on what functionality (methods, properties) are exposed when working with a protocol (in various states of constraint) rather than a concrete type.</div><div class="">4. The ability to dynamically capture and use a concrete type for the purpose of satisfying Self constraints. This one is the least specified at the moment, but seems the best way to deal with Self constraints.</div><div class=""><br class=""></div><div class="">For the first three, I’ve tried to keep the behavior as close to as if I had instead defined a new protocol without self or associated types based on the constraints given, then had every concrete type in the system meeting the old protocol and the constraints be extended to implement the new one. (This model ignores that there are cases you cannot declare extensions like this today, such as extending a protocol to support another protocol, or extending either a concrete type or protocol to support a new protocol conditionally.)</div><div class=""><br class=""></div><div class="">These new protocols include exposing methods which are invariant based on the constraints given, or which have covariant return types (e.g. functions returning Self would indicate they return instances of this protocol). </div><div class=""><br class=""></div><div class="">The rule complexity hopefully will be sophisticated enough to expose (for example) an unbound SequenceType filter method with the approx. signature: “func filter(includedElements:(Any) throws -> Bool ) rethrows -> [Any]” based on existing function/array behavior.</div><div class=""><br class=""></div><div class="">Non-bikeshedded syntax currently is something in the manner of:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">let x:SequenceType = [1,2,3] // no constraints specified whatsoever</div><div class="">let y:protocol<SequenceType where Generator.Element == String> = [“foo”, “bar”] // partially constrained</div></blockquote><div class=""><br class=""></div><div class="">One interesting side-effect to note is that SequenceType could be redefined to only have “Element” as an associated type. Instead of Generator or SubSequence being associated types, methods could return partially constrained GenericType or SequenceType from the appropriate methods. This would be one way of eliminating issues today with recursive use of associated types (as well as SubSequence over-constraining the output of various algorithms to a single concrete type)</div><div class=""><br class=""></div><div class="">For the “opening” of an existential type to find the concrete type it stores dynamically, I’m currently using a different syntax just because the “open x as T” originally given makes ‘open’ a keyword’ and makes it unclear where ’T’ came from - I’m instead overloading the typealias keyword when used within an expression context:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">typealias T = x.dynamicType</div><div class="">let xT = x as! T</div></blockquote><div class=""><br class=""></div><div class="">My next step is to become more familiar with the bounds of what can be done with this today by the AST/SIL. In particular, using “typealias” as above may imply capabilities which are simply more dynamic than is feasible/appropriate to support.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43vFcOQoCM-2FU-2BigXPSqPoICI9ei19Qg7-2B5w5f4pCvB-2B5e77s4Mp9NCIpqAPqmzmXEa7s8WImqA77tznwUsr2BkC3UMqk3CvHDDa4d5Y3wMRtmxhCbjR5GOz7PBbhCJPyc2OBNRED-2FS-2BWEnnw3TlwbjqFUZkJbP1X1pfxiPOp8YFsmrwjwKwEw1X3Phbmlj0Y3xEN-2Fzmmfu8rz28vqm7-2FeE6Q-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="">
</div>
_______________________________________________<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=""></div></body></html>