<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 17, 2016, at 3:06 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'm honestly not sure it makes sense to introduce a proposal just for expressing <Class, Protocol, Protocol> style requirements, and then trying to retrofit fuller support for other existentials onto it. I would prefer that the 'basic package' of existential cases be considered together as a single proposal, unless a core team member expresses their preference otherwise.</div></div></blockquote><div><br class=""></div><div>It also renames protocol<> to Any, but fair enough. </div><div><br class=""></div><div>One reason to keep it separate is that the rename is a breaking change and we should really try to get that into Swift 3. Generalizing existentials is an additive change. I would love to have that in Swift 3 as well, but if it’s not going to make it I don’t think it should hold back the smaller change which is a breaking change.</div><div><br class=""></div><div>Doug, any opinion on this?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 17, 2016 at 1:02 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 17, 2016, at 2:45 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="">Feel free to add as much of this proposal into yours as you want.</div></div></blockquote><div class=""><br class=""></div></span><div class="">The trend is towards smaller proposals and introducing change in stages. Since Adrian’s proposal is almost ready it’s probably best to move ahead with it as-is and follow up with generalized existentials (yours), and then possibly a third on “opening” existentials.</div><div class=""><div class="h5"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev 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=""><div style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class="">+1 for extending my proposal and making `Any<>` even more a powerful beast. :)</div> <br class=""> <div class=""><div style="font-family:helvetica,arial;font-size:13px" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div><div class=""><div class=""> <br class=""><p class="">Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>) schrieb:</p> </div></div><blockquote type="cite" class=""><span class=""><div class=""><div class=""></div><div class=""><div class=""><div class="">
<div dir="ltr" class="">I put together the skeleton of a proposal detailing
enhancements to how associated types can be referenced in Swift 3+.
It's certainly not ready for submission, but I think it gets across
my ideas pretty well. Would love to gather feedback and especially
improvements.
<div class=""><br class=""></div>
<div class="">Be unsparing; whatever form this feature takes will profoundly
affect how Swift developers program for years, so it needs to be
done right.
<div class=""><br class=""></div>
<div class="">See below:</div>
<div class=""><br class=""></div>
<div class=""><b class="">Proposal</b></div>
<div class=""><br class=""></div>
<div class="">
<div class="">An existential type is defined using the "Any<...>"
construct. Existential types can be nested.</div>
<div class=""><br class=""></div>
<div class="">The empty existential type "Any<>" is typealiased to
'Any'.</div>
<div class=""><br class=""></div>
<div class="">Within the angle brackets are zero or more 'clauses'. Clauses
are separated by semicolons. (This is so commas can be used in
where constraints, below. Better ideas are welcome. Maybe it's not
necessary; we can use commas exclusively.)</div>
<div class=""><br class=""></div>
<div class="">There are five different possible clauses:</div>
<div class=""><br class=""></div>
<div class="">
<ul class="">
<li class="">'class'. Must be the first clause, if present. Places a
constraint on the existential to be any class type. (Implies: Only
one can exist. Mutually exclusive with class name
clause.)<br class=""></li>
</ul>
</div>
<div class=""><br class=""></div>
<div class="">(In the future a follow-up proposal should add in 'struct' or
'value' as a counterpart.)</div>
<div class=""><br class=""></div>
<div class="">
<ul class="">
<li class="">Class name. Must be the first clause, if present. (Implies:
Only one can exist. Mutually exclusive with 'class'.) Places a
constraint on the existential (not really an existential anymore)
to be an instance of the class, or one of its
subclasses.<br class=""></li>
</ul>
</div>
<div class="">Example: Any<UIViewController; UITableViewDataSource;
UITableViewDelegate></div>
<div class="">"Any UIViewController or subclass which also satisfies the
table view data source and delegate protocols"</div>
<div class="">
<ul class="">
<li class="">Dynamic protocol. This is entirely composed of the name of a
protocol which has no associated types or Self
requirement.<br class=""></li>
</ul>
</div>
<div class=""><br class=""></div>
<div class="">Example: Any<CustomStringConvertible; BooleanType></div>
<div class="">"Any type which conforms to both the CustomStringConvertible
and BooleanType protocols"</div>
<div class=""><br class=""></div>
<div class="">I'm going to use 'static protocol' to refer to a protocol with
associated types or self requirements. Feel free to propose a more
sound name.</div>
<div class=""><br class=""></div>
<div class="">
<ul class="">
<li class="">Self-contained static protocol, simple. This is composed of the
name of a static protocol, optionally followed by a 'where' clause
in which the associated types can be constrained (with any of the
three basic conformance types: subclassing, protocol conformance,
or type equality). Associated types are referred to with a leading
dot.<br class=""></li>
</ul>
</div>
<div class=""><br class=""></div>
<div class="">Example: Any<Collection where .Generator.Element :
NSObject, .Generator.Element : SomeProtocol></div>
<div class="">"Any type that is a Collection, whose elements are NSObjects
or their subclasses conforming to SomeProtocol."</div>
<div class=""><br class=""></div>
<div class="">
<ul class="">
<li class="">Bound static protocol. This is the same as a self-contained
static protocol, but with a leading "<name> as " which binds
the protocol to a generic typealias. The name can be then be used
in subsequent clauses to build constraints.<br class=""></li>
</ul>
</div>
<div class=""><br class=""></div>
<div class="">Example: Any<T as Collection; IntegerLiteralConvertible
where .IntegerLiteralType == T.Element>.</div>
<div class="">"Any type that is a Collection, and also can be built from an
integer literal, in which the collection elements are the same type
as the type of the integer used for the integer literal
conformance."</div>
<div class=""><br class=""></div>
<div class="">There will be rules to prevent recursive nesting. For example,
if generic typealiases are allowed, they cannot refer to each other
in a circular manner (like how structs can't contain themeselves,
and you can't create a cyclic graph of enums containing
themselves).</div>
<div class=""><br class=""></div>
<div class="">How an existential can be used depends on what guarantees are
provided by the clauses. For example, 'Any<Equatable>' can't
be used for much; if there were any methods on Equatable that did
not use the associated types at all you'd be able to call them, but
that's about it. However, 'Any<Equatable where .Self ==
String>' would allow for == to be called on instances. (This is
a stupid example, since Any<Equatable where .Self == String>
is equivalent to 'String', but there are almost certainly useful
examples one could come up with.)</div>
</div>
<div class=""><br class=""></div>
<div class="">In order of increasing 'power':</div>
<div class="">
<ul class="">
<li class="">Don't constrain any associated types. You can pass around
Any<Equatable>s, but that's about it.</li>
<li class="">Constrain associated types to conform to protocols.</li>
<li class="">Fully constrain associated types.</li>
</ul>
</div>
<div class=""><br class=""></div>
<div class=""><br class=""></div>
</div>
</div></div></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></div></span></blockquote></div><br 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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></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></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>