I really like this solution and perhaps you can also go @projectable(&quot;empyValue&quot;) if the default name is a bad choice. See @obc for similar usage.<span></span><br><br>On Thursday, 10 December 2015, Alex Lew via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Semantically, I believe enums with more than one associated value are actually just enums with one associated value, of tuple type.<div><br></div><div>I&#39;m not convinced it would be bad to do magic function generation, but it&#39;s worth considering explicit syntax. If we were to use @ compile-time attributes, maybe it could be a word before the case -- like @projectable or @selectable (or some better name)?</div><div><br></div><div>enum List&lt;T&gt; {</div><div>     @projectable case Empty</div><div>     indirect case FirstAndRest(T, List&lt;T&gt;)</div><div>}</div><div><br></div><div>generates:</div><div>myList.isEmpty() -&gt; Bool</div><div><br></div><div>Another option: some sort of @reflectable attribute on the enum itself.</div><div><br></div><div>@reflectable enum Pet {</div><div>     case Cat(name: String, color: String)</div><div>     case Dog(name: String, breed: String)</div><div>     case Bear(name: String, isHibernating: Bool)</div><div>}</div><div><br></div><div>And one other option, in a very different direction, that seems weird but maybe has its benefits:</div><div><br></div><div>What if we exposed an associatedValue computed property of type Any? (It would be unit type for cases with no associated value.)</div><div><br></div><div>You could then do something like this:</div><div><br></div><div>enum Contact {</div><div>     case Person(String) // name</div><div>     case Business(String) // org name</div><div>     case FamilyMember(String) // relation name</div><div>     case RecentCall(Int) // a contact from caller id, only store the phone number</div><div><br></div><div>     func name() -&gt; String {</div><div>          return associatedValue as? String ?? &quot;Unknown (\(associatedValue as! Int))&quot;</div><div>     }</div><div>}</div><div><br></div><div>Essentially, it allows you to project out a relatively common associated value (in this case a string) without much boilerplate. It&#39;s also just one thing for the compiler to generate, instead of <i>n</i>. Not crazy about any of these... just brainstorming. It may also be that a concise switch-like control flow expression eliminates the need for this.</div><div><br></div><div>-Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 11:49 AM, <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;thorsten@portableinnovations.de&#39;);" target="_blank">thorsten@portableinnovations.de</a> <span dir="ltr">&lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;thorsten@portableinnovations.de&#39;);" target="_blank">thorsten@portableinnovations.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div>
<div>
 <span style="background-color:rgba(255,255,255,0)">I would prefer if no &quot;magic&quot; methods would be generated automatically, but only when marked with @derivestandardmethods (fill in better name here).</span>
</div>
<div>
 <span style="background-color:rgba(255,255,255,0)"><br></span>
</div>
<div>
 <span style="background-color:rgba(255,255,255,0)">As to naming I like the proposal #1 by Alex.</span>
</div>
<div>
 <span style="background-color:rgba(255,255,255,0)"><br></span>
</div>
<div>
 <span style="background-color:rgba(255,255,255,0)">What about enums with more than one associated value?</span><span><font color="#888888">
</font></span></div><span><font color="#888888">
<div>
 <span style="background-color:rgba(255,255,255,0)"><br></span>
</div>
<div>
 <span style="background-color:rgba(255,255,255,0)">-Thorsten</span>
</div></font></span><div><div>
<div>
 <br>Am 09.12.2015 um 07:29 schrieb Alex Lew via swift-evolution &lt;
 <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a>&gt;:
 <br>
 <br>
</div>
<blockquote type="cite">
 <div>
  <div dir="ltr">
   Thanks, Chris, for all the time you&#39;re putting into responding to these proposals (and the kindness with which you&#39;re responding!). I really like that solution.
   <div>
    <br>
    <div>
     <div>
      Brainstorming some names for the auto-generated functions:
     </div>
     <div>
      <br>
     </div>
     <div>
      1. If a case has no associated values, isX() -&gt; Bool is generated, where X is the case name.
     </div>
     <div>
          If a case has an associated value of type T, asX() -&gt; T? is generated, where X is the case name.
     </div>
    </div>
    <div>
         This mirrors is/as? operators, which return Bool / Optional respectively.
    </div>
    <div>
     2. projectX() -&gt; Bool / projectX() -&gt; T?
    </div>
    <div>
     3. isX() -&gt; Bool / xValue() -&gt; T?
    </div>
    <div>
     <br>
    </div>
    <div>
     Another option (probably the wrong option, but it&#39;s worth putting out there) is that instead of returning Bool in the no-associated-value case, we return ()?. This would make me feel better about using the same naming convention (asX(), projectX(), xValue(), etc.) for each case, and would allow for != nil checks on all cases. But it would probably be a little confusing for newcomers to the language.
    </div>
    <div>
     <br>
    </div>
    <div>
     <div>
      One (potentially misguided) question. I noticed in proposal 0002 (on removing function currying) that there are &quot;plans to move away from the arguments-are-a-single-tuple model&quot; in the near future. Would this also affect associated values of enums? That is, might
     </div>
     <div>
      <br>
     </div>
     <div>
      case Dog(name: String, age: Int, breed: String)
     </div>
     <div>
      <br>
     </div>
     <div>
      one day not have the semantics of a single associated value of type (name: String, age: Int, breed: String)? Or is the de-ML-ification planned only for function arguments?
     </div>
    </div>
    <div>
     <br>
    </div>
    <div>
     -Alex
    </div>
   </div>
  </div>
  <div class="gmail_extra">
   <br>
   <div class="gmail_quote">
    On Wed, Dec 9, 2015 at 12:45 AM, Chris Lattner 
    <span dir="ltr">&lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;clattner@apple.com&#39;);" target="_blank">clattner@apple.com</a>&gt;</span> wrote:
    <br>
    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
     <span><br> &gt; On Dec 7, 2015, at 8:05 PM, Alex Lew via swift-evolution &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br> &gt;<br> &gt; Hi all,<br> &gt;<br> &gt; Curious to hear thoughts on allowing non-binding pattern matches to be used as boolean values outside of an if, guard, for...in, while, switch, etc. Something like:<br> &gt;<br> &gt; enum List&lt;T&gt; {<br> &gt;      case Empty<br> &gt;      indirect case Link(T, List&lt;T&gt;)<br> &gt;<br> &gt;      func isEmpty() -&gt; Bool {<br> &gt;           return case .Empty = self<br> &gt;      }<br> &gt; }<br> <br> </span>I agree with you that this is a problem that we should solve, but I think it could be solved in a different way.  Imagine if:
     <br> 
     <br> enum Foo {
     <br>   case X(a : Float), Y, Z(a : Int)
     <br> }
     <br> 
     <br> automatically synthesized these members (the exact names are just a strawman proposal, not serious :-)
     <br> 
     <br> extension Foo {
     <br>   func isX() -&gt; Float? {…}
     <br>   func isY() -&gt; Bool {…}
     <br>   func isZ() -&gt; Int? {…}
     <br> }
     <br> 
     <br> This would tie into all of the mechanics we have for dealing with optionals, e.g. if/let and ??
     <br> 
     <span><font color="#888888"><br> -Chris</font></span>
    </blockquote>
   </div>
   <br>
  </div>  
 </div>
</blockquote>
</div></div><div><div><blockquote type="cite">
 <div>
  <span>_______________________________________________</span>
  <br>
  <span>swift-evolution mailing list</span>
  <br>
  <span><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a></span>
  <br>
  <span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span>
  <br>
 </div>
</blockquote>
<div style="margin-top:10px;font-size:12px;font-family:Helvetica,Arial;color:#999">
 Untracked with 
 <a style="color:#999" href="https://trackbuster.com/?sig" target="_blank">Trackbuster</a>
</div></div></div></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uQDHC8-2Bb5Mm2h8Fr1ebZpHulz7MNVAtz7ytkHH1B6sCvMqhblCu-2FtishBvo8NtHZrP4U-2FJqTGbBAim-2F7GB2sw3hKh4p9q23gPE9ZxSpdJqNiz3QG1-2FWGakSUpmlk6PWXscxYX6MM3Kn1fBzGnEezQ-2FW1GrPKNIWbn1SVPe-2BKsgEwROSylxAZnUF606nSYeitPg-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</blockquote>