<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 19, 2016 at 11:07 AM, Tino Heth 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Cao,<br>
<br>
Considering "&" for types is already decided, symmetry would be enough motivation for me to add "|" as well.<br></blockquote><div><br></div><div>Tino, this line of reasoning was explicitly addressed by the core team when they approved "&". In fact, it was their "princip[al] concern" about "&":</div><div><br></div><div>"<span style="color:rgb(0,0,0);white-space:pre-wrap">The principle concern with this is that having an “&" operator for generic constraints leads the question of whether the language should introduce an "|" operator to represent disjunctions in type constraints (something that the type system cannot and should not support). This is a topic that the C++ committee grappled with in its discussions of C++ concepts. That said, the core team feels that “&” directly expresses the relationship that we want, that “|” can be addressed in the “commonly rejected proposals" list, and that other proposals for an infix operator (like +) skirt this issue but are strictly worse at communicating intent in code."</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Maybe I would even support replacing enums with associated values in favor of union types (my impression is that enums aren't as useful as I thought when I started using them).<br>
<br>
But right now, this doesn't seem to be a time for discussing huge changes, but for actually implementing smaller ones ;-)<br>
I'm a little bit concerned that Swift might already be preferring compatibility over elegance, but the defensive attitude that you perceived might as well be explained with release-stress…<br>
<br>
Of course, rejection is still frustrating — but please consider that most proposals aren't accompanied by an implementation, so every wish that's accepted adds something to the pile of work to be done by the core team.<br>
Imho it would be nice if Swift evolution would be more "decentralized", moving away from proposals like "I want to have feature X" towards "I want to develop feature X, is there a chance this could be integrated?", but coordination is already hard enough, so this might be unfeasible.<br>
<br>
- Tino<br>
<div class=""><div class="h5">______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>