<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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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. 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. 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. In these cases you may well prefer to use polymorphism rather than switch statements in the implementation. </div><div><br></div><div>I see no reason to have "one true way". Each approach has pros and cons. An engineering tradeoff is required. 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. 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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></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>