<div dir="ltr"><div>To the topic at hand, the project I’m currently working on has 2 enums, both with String raw values. For comparison, it has 3 classes (a Formatter subclass, the app delegate, and one more), 4 protocols, and 47 structs.</div><div><br></div><div>One of the enums exists to select among the handful of struct types which conform to one of the protocols.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There are several things we have thought of that could potentially improve the situation, most notably exposing each case as an optional property.</blockquote><div><br></div><div>That would be very nice.</div><div><br></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">I&#39;d also really like to see switch-expressions (as opposed to statements).</blockquote><div><br></div><div>Hmm, would a syntax like this be appropriate?</div><div><br></div><div>switch someValue -&gt; [String] {</div><div>    case .helloWorld: return [&quot;Hello&quot;, &quot;world&quot;]</div><div>    default: return []</div><div>}</div><div><br></div><div>That way the existing switch statement could remain as-is, and the familiar function syntax would be used to specify the return type for switch expressions. The “return” keyword could even be elided for single-line cases as well, much like closures.</div><div><br></div><div>…oh, I just realized we’re on -users not -evolution here. Perhaps I’ll bring this up next time switch expressions are proposed.</div><div><br></div><div>Nevin</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 6, 2016 at 4:31 PM, Dave Abrahams via swift-users <span dir="ltr">&lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt;</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"><span class="gmail-"><br>
on Sun Nov 06 2016, Tino Heth &lt;swift-users-AT-swift.org&gt; wrote:<br>
<br>
&gt; Enums are a fundamental part of Swift, so I guess they won&#39;t change<br>
&gt; much — but I wonder if anyone shares my observations in real-life use…<br>
&gt;<br>
&gt; Afair, there are three different types of enums:<br>
&gt; - Enums with raw values<br>
&gt; - enums with associated objects<br>
&gt; - Plain enums (no underlying value)<br>
&gt;<br>
&gt; I use the first type quite often (as a convenient way to create string<br>
&gt; constants, or for serialization), but see no real value in plain enums<br>
&gt; (they offer nothing over enums backed with a raw value).<br>
&gt;<br>
&gt; The second type is special:<br>
&gt; It looks like a really cool concept, and and I started several designs<br>
&gt; based on them — just to realize later that structs and classes are a<br>
&gt; better fit.<br>
&gt; My conclusion so far is that enums perform bad as soon as you want to<br>
&gt; attach additional data or behavior; one or two computed properties are<br>
&gt; ok, but those switch-statements quickly become a burden.<br>
&gt; There are some options to work around this problem, but I guess I&#39;ll<br>
&gt; just stay away from enums with associated objects by default (with the<br>
&gt; exception of error-types — imho those can be modeled quite nicely).<br>
&gt;<br>
&gt; So, that&#39;s my current perception, and I&#39;m curious if others had<br>
&gt; similar experiences — or, even more interesting, completely different<br>
&gt; observations and elegant solutions based on enums.<br>
<br>
</span>I have personally always found that exuberant use of that kind of enum<br>
results in ergonomics and readability difficulties.  There are several<br>
things we have thought of that could potentially improve the situation,<br>
most notably exposing each case as an optional property.  I&#39;d also<br>
really like to see switch-expressions (as opposed to statements).  I&#39;m<br>
not sure if that&#39;s really all we need in order to allow enums to reach<br>
their potential, though.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-users</a><br>
</div></div></blockquote></div><br></div></div>