Maybe I'm not getting something. But if you only want T | U | V to expose members required by common protocols P, Q, and R, since you know the types at compile time, you also know the common protocols. Why wouldn't you just write P & Q & R, and if necessary precondition(x is T || x is U || x is V)?<br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 20, 2016 at 12:35 Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Aug 20, 2016, at 10:36 AM, Haravikk <<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>> wrote:<br>
><br>
><br>
>> On 19 Aug 2016, at 15:38, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> Ad-hoc enums have been discussed already, at length, and all the weaknesses touched on then still apply now. For instance, since they're ad-hoc, can you pass an instance of type "Int | String" as an argument if the function expects a "String | Int | Float"? Enums don't have duck typing behavior like that; if your ad-hoc type does, then it's not very much like an enum; if it doesn't, it won't feel much like a union type.<br>
><br>
> While ad-hoc enums are certainly similar I don't think that this problem applies to unions; the problem with ad-hoc enums is that while cases may have the same name, the meaning of a case may not be identical, so compatibility is uncertain. For type unions I'd say this isn't an issue; I'd say that yes, String | Int is compatible with String | Int | Float as every possible value can be carried over (whereas the reverse is not true), they're just values of one of several types, so as long as the conversion is possible, it should be fine to pass it on (or rather, repackage it behind the scenes).<br>
><br>
>> Moreover, an ad-hoc "String | Int" may look like a union type, but until switching over an instance to cast it, you can't invoke any methods common to String and Int. So it really doesn't feel like a union type at all.<br>
><br>
> Could it not do that though? I'd say that a union type should conform to any common protocols that its members conform to; if this can be done in the initial release then great, otherwise it can come later.<br>
<br>
Conforming to common protocols would be much better than an implicit ad-hoc / duck-typed protocol that simply exposes all common members. But there is strong opposition to unions, much of which is related to implementation complexity. It seems to me that the path to having unions or a union-ish feature receiving serious consideration is to demonstrate the value they can offer even with relatively restricted functionality (such as syntactic sugar for enums with implicit lifting). If that is successful we will have an opportunity to work with them and make a case for enhancements in the future.<br>
<br>
Also, it won't always possible for a union to conform to a protocol conformed to by all member types. If the protocol has `Self` requirements in argument position it would not be able to conform and if it has associated type requirements which are bound to different concrete types in the types making up the union it would also not be able to conform.<br>
<br>
Matthew</blockquote></div>