<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><blockquote type="cite" class="clean_bq"><div dir="ltr">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></blockquote><div><div dir="ltr"><br></div></div><div dir="ltr">I don’t see the point why we couldn’t do that! I mean if we add to much into a single proposal it would have more chances to be rejected. Besides that Chris already did the same with his `generic typealias` proposal where the whole feature was only introduced in its base form, which will gain more constraints later on. I don’t think the base form of `Any<>` gaining more constraints will break any code later, when there are no significant changes in syntax.</div><div dir="ltr"><br></div><div dir="ltr"><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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;"><div dir="ltr"><span style="font-family: 'normal helvetica', sans-serif;">Another area you didn’t touch on is whether Any constructs (and typealiases referring to them) should be usable as generic constraints. I would expect this to be possible but I think we need to spell it out.</span></div></blockquote></div><p>I was thinking about this while looking at `var view: Any<UIView, SomeProtocol>`. If UIView does not conform to SomeProtocol you won’t be able to construct that type because otherwise it just would be `UIView`.</p><p>One would only be able to construct `Any<>` if it can be inferred to a single type like `SomeClass`. Thats what I thought and dropped from mentioning that. </p><p><br></p><p>Btw. I submitted a pull request already, but I noted in my proposal in the future directions section the following:</p><ul class="added rich-diff-level-zero" style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; box-shadow: rgb(127, 203, 92) 4px 0px 0px inset; border-top-left-radius: 0px; border-top-right-radius: 0px; border-bottom-right-radius: 0px; border-bottom-left-radius: 0px; border-top-width: 0px; border-bottom-width: 0px; background-color: rgb(234, 255, 234); color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px;"><li class="rich-diff-level-one" style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; margin-left: 15px;"><p style="box-sizing: border-box; margin-top: 16px; margin-bottom: 16px;"><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.600000381469727px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;">Any<></code> should reflect powerful generalized generic features to be able to constrain types even further. (This should have its own proposal, which will extend <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.600000381469727px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;">Any<></code> proposed here.)</p></li></ul></div></div> I hope my English wasn't too bad, please don’t blame me. :D<div><br> <div id="bloop_sign_1463515996856070912" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 17. Mai 2016 bei 22:07:00, Austin Zheng (<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr"><div><br></div>
<div>Austin</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 17, 2016 at 1:02 PM, Matthew
Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br>
<div>
<blockquote type="cite">
<div><span class="">On May 17, 2016, at 2:45 PM, Austin Zheng via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>
wrote:</span></div>
<span class=""><br></span>
<div>
<div dir="ltr"><span class="">Feel free to add as much of this
proposal into yours as you want.</span></div>
</div>
</blockquote>
<div><span class=""><br></span></div>
<div>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>
<div class="h5"><br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div><br></div>
<div>Austin</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 17, 2016 at 12:09 PM, Adrian
Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<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 style="font-family:Helvetica,Arial;font-size:13px;margin:0px">
+1 for extending my proposal and making `Any<>` even more a
powerful beast. :)</div>
<br>
<div>
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<div>
<div><br>
<p>Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution
(<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</p>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div>
<div>
<div dir="ltr"><span>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.</span>
<div><span><br></span></div>
<div><span>Be unsparing; whatever form this feature takes will
profoundly affect how Swift developers program for years, so it
needs to be done right.</span>
<div><span><br></span></div>
<div><span>See below:</span></div>
<div><span><br></span></div>
<div><span><b>Proposal</b></span></div>
<div><span><br></span></div>
<div>
<div><span>An existential type is defined using the
"Any<...>" construct. Existential types can be
nested.</span></div>
<div><span><br></span></div>
<div><span>The empty existential type "Any<>" is typealiased
to 'Any'.</span></div>
<div><span><br></span></div>
<div><span>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.)</span></div>
<div><span><br></span></div>
<div><span>There are five different possible clauses:</span></div>
<div><span><br></span></div>
<div>
<ul>
<li><span>'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></span></li>
</ul>
</div>
<div><span><br></span></div>
<div><span>(In the future a follow-up proposal should add in
'struct' or 'value' as a counterpart.)</span></div>
<div><span><br></span></div>
<div>
<ul>
<li><span>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></span></li>
</ul>
</div>
<div><span>Example: Any<UIViewController; UITableViewDataSource;
UITableViewDelegate></span></div>
<div><span>"Any UIViewController or subclass which also satisfies
the table view data source and delegate protocols"</span></div>
<div>
<ul>
<li><span>Dynamic protocol. This is entirely composed of the name
of a protocol which has no associated types or Self
requirement.<br></span></li>
</ul>
</div>
<div><span><br></span></div>
<div><span>Example: Any<CustomStringConvertible;
BooleanType></span></div>
<div><span>"Any type which conforms to both the
CustomStringConvertible and BooleanType protocols"</span></div>
<div><span><br></span></div>
<div><span>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.</span></div>
<div><span><br></span></div>
<div>
<ul>
<li><span>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></span></li>
</ul>
</div>
<div><span><br></span></div>
<div><span>Example: Any<Collection where .Generator.Element :
NSObject, .Generator.Element : SomeProtocol></span></div>
<div><span>"Any type that is a Collection, whose elements are
NSObjects or their subclasses conforming to
SomeProtocol."</span></div>
<div><span><br></span></div>
<div>
<ul>
<li><span>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></span></li>
</ul>
</div>
<div><span><br></span></div>
<div><span>Example: Any<T as Collection;
IntegerLiteralConvertible where .IntegerLiteralType ==
T.Element>.</span></div>
<div><span>"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."</span></div>
<div><span><br></span></div>
<div><span>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).</span></div>
<div><span><br></span></div>
<div><span>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.)</span></div>
</div>
<div><span><br></span></div>
<div><span>In order of increasing 'power':</span></div>
<div>
<ul>
<li><span>Don't constrain any associated types. You can pass around
Any<Equatable>s, but that's about it.</span></li>
<li><span>Constrain associated types to conform to
protocols.</span></li>
<li><span>Fully constrain associated types.</span></li>
</ul>
</div>
<div><span><br></span></div>
<div><span><br></span></div>
</div>
</div>
</div>
</div>
<span>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</span></div>
</div>
</blockquote>
</div>
<br>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
<br></blockquote>
</div>
<br></div>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</div>
</blockquote>
</div>
</div>
</div>
<br></div>
</blockquote>
</div>
<br></div>
</div></div></span></blockquote></div></body></html>