<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Feb 19, 2017, at 9:57 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div>Left unsaid from my reply about enums is that implicit conversions should absolutely be added. We already have this magic for one particular enum, Optional.</div></div></blockquote><div><br></div><div>+1. &nbsp;I cover a design to enable this in my value subtyping manifesto.</div><br><blockquote type="cite"><div><div><br></div><div>I'm not arguing with you that enums are currently unsuitable. In fact I entirely agree. But Chris Lattner and others have said (now I'm paraphrasing, but I believe accurately) that they *should* be. What will it take? At minimum, some way to opt into implicit conversions. It's a no-brainer in my mind.</div><div><br></div><div>Bottom line: the language needs one excellent way to model Foo | Bar | Baz, not two or three mediocre workarounds. The core team has said that they want that excellence to be built through enums. Let's do it.</div></div></blockquote><div><br></div><div>I would love to hear your thoughts on my value subtyping manifesto which covers a plethora of enum enhancements, including everything relevant to and discussed in this thread.</div><div><br></div><div>That said, there are cases where enums are not appropriate and a closed protocol is more appropriate. &nbsp;Specifically when the set of types is expected to evolve over time <span style="background-color: rgba(255, 255, 255, 0);">or is large enough that an enum is a bit unwieldy,</span> but is still intended to be controlled by the library. &nbsp;In these cases you may well prefer to use polymorphism rather than switch statements in the implementation. &nbsp;</div><div><br></div><div>I see no reason to have "one true way". &nbsp;Each approach has pros and cons. &nbsp;An engineering tradeoff is required. &nbsp;The fact that one solution may be the most appropriate in the majority of cases is no reason to preclude the alternative from being available. &nbsp;It may be the better choice in a nontrivial minority of cases, which is plenty frequently enough to justify its availability.</div><br><blockquote type="cite"><div><div><br></div><div><br></div><div><div class="gmail_quote"><div>On Sun, Feb 19, 2017 at 21:28 Zach Waldowski via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div style="font-family:Arial" class="gmail_msg">On Sun, Feb 19, 2017, at 06:40 PM, Xiaodi Wu via swift-evolution wrote:<br class="gmail_msg"></div>
</div><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div style="font-family:Arial" class="gmail_msg">On Sun, Feb 19, 2017 at 5:15 PM, Brent Royal-Gordon via swift-evolution <span class="gmail_msg">&lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br class="gmail_msg"></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class="gmail_msg"><div style="font-family:Arial" class="gmail_msg">What is the harm of permitting an outside conformance to `SQLiteValue`?<br class="gmail_msg"></div>
</blockquote></div></div></div></blockquote></div><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"></div>
</div>
</div>
</blockquote><div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">I'll put words in Brent's mouth here as an attempt at an answer: you sometimes need to exclusively switch a downcast of an existential. Consider a serialization type - or SQLiteValue - where need to treat specific fundamental types ("primitives") in implementation-dependent ways. In a theoretical serialization design, all non-primitives would have an explicit protocol of semantics to conform to support serialization, much like the stdlib's "Custom" protocol pattern, and you compose from there.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">Using an enum to represent this exclusivity remains unconvincing to me, unless we choose to add implicit conversions to the language. `.int(42)` is an overwhelming level of duplicate type information in any practical, non-trivial use case. Yes, (closed) enums model exclusivity. They are not the only things to do so.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">The stdlib alone is reason enough for this feature to exist, even if not exposed publicly.<br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
<div style="font-family:Arial" class="gmail_msg">Zachary</div>
<div style="font-family:Arial" class="gmail_msg"><br class="gmail_msg"></div>
</div>

_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></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">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>