<div dir="ltr">I think this proposal should stick to the intersection type: a type which inherits from at most one class (multiple inheritance should definitely be a separate proposal) if it conforms to all of one or more specified protocols.<div><br></div><div>The immediate problem I see with a union type is using it. If I&#39;m understanding it right, this would let me define a union type of any&lt;UITextView, UITextField&gt;, to a variable &#39;textControl&#39;. I might then be able to set &#39;textControl.text&#39; to a value, regardless of whether it&#39;s actually a UITextView or UITextField. But the correct way to do this would be to create a protocol (say) &#39;HasTextProperty&#39;, extend UITextView and UITextField to conform to HasTextProperty, and use that. The intersection type would even let us extend the type safety of &#39;textControl&#39; to &#39;all&lt;UIView, HasTextProperty&gt;&#39;.</div><div><br></div><div>The next issue I&#39;d see with the union type is that it&#39;s the already proposed Either type.</div><div><br></div><div>-- Ross</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 1:10 PM, Maximilian Hünenberger <span dir="ltr">&lt;<a href="mailto:m.huenenberger@me.com" target="_blank">m.huenenberger@me.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>I don&#39;t see union and intersection types either in the &quot;goals list&quot; or in the &quot;non-goals list&quot;. Either way it should be a separate proposal.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Maximilian</div></font></span><div><div class="h5"><div><br>Am 11.02.2016 um 09:29 schrieb Thorsten Seitz &lt;<a href="mailto:tseitz42@icloud.com" target="_blank">tseitz42@icloud.com</a>&gt;:<br><br></div><blockquote type="cite"><div><div></div><div>Ceylon uses &amp; for intersection types (and | for union types) which I find quite intuitive, meaning a type which conforms to this AND that protocol/type (OR in the case of unions).</div><div><br></div><div>It works like expected, i.e.</div><div>A &amp; B &amp; A == A &amp; B </div><div><br></div><div>or</div><div>typealias A = B &amp; C</div><div>A &amp; C == B &amp; C</div><div>A &amp; D == B &amp; C &amp; D</div><div><br></div><div>class A&lt;T&gt; {</div><div>        var x: T &amp; B</div><div>}</div><div><br></div><div>var a: A&lt;C&gt;</div><div>a.x has type C &amp; B</div><div><br></div><div>var b: A&lt;B&gt;</div><div>b.x has type B</div><div><br></div><div>etc.</div><div><br></div><div>-Thorsten </div><div><br></div><div><br></div><div>Am 10.02.2016 um 14:59 schrieb Ross O&#39;Brien via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;:<br><br></div><blockquote type="cite"><div><div dir="ltr">I agree with everything Brent just said.<div>My question would then be: how does this extend?</div><div><br></div><div>Continuing the example:</div><div>&#39;typealias ViewControllerTableViewDataSource = all&lt;UIViewController, UITableViewDataSource&gt;&#39;</div><div><br></div><div>It should then be possible to have a subtype of this which also conforms to UITableViewDelegate.</div><div>So, given the above, this would work:</div><div>&#39;typealias ViewControllerTableViewPackage = all&lt;UIViewController, UITableViewDataSource, UITableViewDelegate&gt;&#39;.</div><div>Would this also work?</div><div>&#39;typealias ViewControllerTableViewPackage = all&lt;ViewControllerTableViewDataSource, UITableViewDelegate&gt;&#39;<br></div><div>Assuming someone defined this typealias: &#39;typealias TableViewPackage = protocol&lt;UITableViewDataSource, UITableViewDelegate&gt;&#39;, would the above also be equivalent to this?:</div><div>&#39;typealias ViewControllerTableViewPackage = all&lt;UIViewController, TableViewPackage&gt;&#39;</div><div><br></div><div>The TableViewPackage protocol, defined above, is considered by Swift to be a &#39;non-nominal type&#39;. Thus this is illegal:</div><div>&#39;extension TableViewPackage&#39;</div><div>(I don&#39;t know why. Perhaps a type conforming to the separate protocols has to opt-in to the combination?)</div><div><br></div><div>However, we can have the following:<br></div><div>&#39;extension UITableViewDelegate where Self : UITableViewDataSource&#39;</div><div>&#39;extension UITableViewDelegate where Self : UIViewController&#39;</div><div>&#39;extension UITableViewDelegate where Self : UIViewController, Self : UITableViewDataSource&#39;</div><div><br></div><div>Similarly we can&#39;t currently have this:</div><div>&#39;extension UIViewController where Self : UITableViewDataSource, UITableViewDelegate&#39;</div><div>because UIViewController is not a generic type (and this is part of the original complaint).</div><div><br></div><div>It would be nice to be able to write this out as: &#39;extension all&lt;UIViewController, UITableViewDataSource, UITableViewDelegate&gt;&#39;, even if it&#39;s just syntactic sugar for &#39;extension UITableViewDelegate where Self : UIViewController, Self : UITableViewDataSource&#39;.</div><div><br></div><div>-- Ross</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 1:44 PM, Maximilian Hünenberger <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the thread &quot;Partially constrained protocols&quot; we have discussed a similar approach using where clauses:<br>
<br>
        protocol&lt;MyProtocol where Self: UIViewController&gt;<br>
<br>
- Maximilian<br>
<div><div><br>
Am 10.02.2016 um 14:00 schrieb Brent Royal-Gordon via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;:<br>
<br>
&gt;&gt; So, I definitely think there is room for improvement here… how about recycling the inheritance syntax?<br>
&gt;&gt;<br>
&gt;&gt; let controller: (UIViewController, UITableViewDatasource)<br>
&gt;<br>
&gt; This declares a tuple containing a UIViewController and a UITableViewDataSource.<br>
&gt;<br>
&gt;&gt; I added the braces because it would be really when you add the question mark for an optional value; an alternative for this case would be<br>
&gt;&gt;<br>
&gt;&gt; let controller: Optional&lt;UIViewController, UITableViewDatasource&gt;<br>
&gt;<br>
&gt; This attempts to declare an optional with two generic types, which doesn&#39;t work because Optional only has one type parameter. (But other types, like Dictionary, *do* take two type parameters.)<br>
&gt;<br>
&gt; Swift does already have a syntax for declaring that a type must conform to two (or more!) protocols:<br>
&gt;<br>
&gt;    let controller: protocol&lt;UITableViewDataSource, UITableViewDelegate&gt;<br>
&gt;<br>
&gt; I think this could probably be extended to support one class type as well, perhaps with a new name:<br>
&gt;<br>
&gt;    let controller: all&lt;UIViewController, UITableViewDataSource&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Brent Royal-Gordon<br>
&gt; Architechies<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <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>
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>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></div></div></div></blockquote></div><br></div>