<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 3:02 PM Vladimir.S &lt;<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> &gt; in other words, we could consider allowing this:<br>
 &gt;    func foo(bar: (.fit | .fill)) {<br>
 &gt;      baz(bar: bar)<br>
 &gt;    }<br>
 &gt;    func baz(bar: (.fit | .fill | .florp) { ... }<br>
 &gt;<br>
 &gt; In other words, an ad hoc enum T can be used wherever an ad hoc enum U is<br>
 &gt; expected if T ⊆ U.<br>
<br>
Can&#39;t agree with this. Just because the same analogue with tuples :<br>
differently defined tuples are different types. Tuples with different order<br>
of types in declaration - are different types. So I expect here instance of<br>
(.fit | .fill) `bar` is not of the same type as (.fit | .fill | .florp)<br></blockquote><div><br></div><div>I would argue that the analogy to tuples doesn&#39;t apply in this case. For tuples, order of the arguments matters, and part of the structural definition of a tuple is the number of its elements. Neither of those applies for an ad hoc enum—it is defined solely as a set of named cases.</div><div><br></div><div>After writing that, however, that *does* seem like the kind of implicit conversion that Swift tends to avoid. So maybe an explicit conversion would better fit the language design.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But +1 to be able to &#39;convert&#39; instance of (.fit | .fill) to instance of<br>
(.fit | .fill | .florp). For example(if we&#39;ll have init(caseName) and<br>
.caseName for enums):<br>
<br>
func foo(bar: (.fit | .fill)) {<br>
     let bazbar = (.fit | .fill | .florp).init(caseName: bar.caseName)<br>
     baz(bar: bazbar)<br>
}<br>
func baz(bar: (.fit | .fill | .florp) { ... }<br></blockquote><div><br></div><div>I&#39;m not crazy about this because I would expect a conversion that requires a round-trip transformation of the string case name to be negative for performance. Why not just:</div><div><br></div><div>    let bazbar = (.fit | .fill | .florp)(bar)</div><div><br></div><div>which the compiler ought to be able to optimize much better?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 02.06.2016 0:38, Tony Allevato wrote:<br>
&gt; I find myself agreeing with the idea that ad hoc enums are to enums as<br>
&gt; structs are to tuples. Based on that analogy, why should an ad hoc enum<br>
&gt; *need* a name (autogenerated or otherwise) any more than a tuple needs a<br>
&gt; name? Would those who dislike ad hoc enums argue that this also shouldn&#39;t<br>
&gt; be allowed:<br>
&gt;<br>
&gt;     func foo(bar: (x: Int, y: Int)) {}<br>
&gt;     let t: (x: Int, y: Int) = (x: 5, y: 5)<br>
&gt;<br>
&gt; If someone writes `(.fit | .fill)` (or whatever the hypothetical syntax<br>
&gt; might be), that should just *be* the type the same way that `(x: Int, y:<br>
&gt; Int)` is a type without a name, and that type can be used in argument<br>
&gt; lists, variables, or whatever. There shouldn&#39;t be any worry about<br>
&gt; declarations across multiple functions colliding or being incompatible any<br>
&gt; more than we would worry about two functions declaring arguments of type<br>
&gt; `(x: Int, y: Int)` would collide or be incompatible.<br>
&gt;<br>
&gt; One side of ad hoc enums that I&#39;d like to see explored is that, by being<br>
&gt; unnamed, they&#39;re basically anonymous finite sets and we could apply<br>
&gt; well-defined subset relationships to them: in other words, we could<br>
&gt; consider allowing this:<br>
&gt;<br>
&gt;     func foo(bar: (.fit | .fill)) {<br>
&gt;       baz(bar: bar)<br>
&gt;     }<br>
&gt;     func baz(bar: (.fit | .fill | .florp) { ... }<br>
&gt;<br>
&gt; In other words, an ad hoc enum T can be used wherever an ad hoc enum U is<br>
&gt; expected if T ⊆ U.<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Jun 1, 2016 at 1:43 PM L. Mihalkovic via swift-evolution<br>
&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     &gt; On Jun 1, 2016, at 6:51 PM, Vladimir.S &lt;<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a><br>
&gt;     &lt;mailto:<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>&gt;&gt; wrote:<br>
&gt;     &gt;<br>
&gt;     &gt; Yes, I also can support the idea of autogenerated type name (like<br>
&gt;     Enum_fit_OR_fill) as long as it allows to do all the things we are<br>
&gt;     discussing here: declare (.fit|.fill) in function, use .fit on calling<br>
&gt;     side, use (.fit|.fill) to declare temporary variable of type compatible<br>
&gt;     with such function parameter etc.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     It all works because the compiler is just being a thoughless scribe<br>
&gt;     that just writes the standard enum we don&#39;t bother to write ourselves.<br>
&gt;     Because the heuristic is simple and straightforward then it is<br>
&gt;     predictible. The enum can be used with its long name be ause it is a<br>
&gt;     real enum. And writing the short form of it also works because the<br>
&gt;     compiler knowns uniquely what the long name is everytime it runs into<br>
&gt;     the short name.<br>
&gt;<br>
&gt;<br>
&gt;     &gt; But how do you suggest to define a type of such function in<br>
&gt;     `typealias` for example? i.e. for func my(option: (.fit|.fill) {..}<br>
&gt;     &gt;<br>
&gt;     &gt; typealias MyFunc = ((.fit|.fill)) -&gt; ()<br>
&gt;     &gt; or as<br>
&gt;     &gt;<br>
&gt;     &gt; typealias MyFunc = (Enum_fit_OR_fill) -&gt; ()<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Ideally there is no difference whatsoever, there is a single enum, it<br>
&gt;     is produced at the module level, and it has the long form name.<br>
&gt;<br>
&gt;     There can be rules that would prevent us from doing that with<br>
&gt;     externally visible APIs, if the core team fuges that we should take the<br>
&gt;     time to write our enums manually and cleanly to make them visible to<br>
&gt;     the world, but it is not a necessary rule.<br>
&gt;<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt; But I still can&#39;t support the idea of limiting the usage of such<br>
&gt;     enums - i.e. &quot;To deal with milti site definition, the compiler would<br>
&gt;     simply flag a error/warning, or be silent in the presence of a new<br>
&gt;     annotation:&quot;. I really think we need then introduce the same rule for<br>
&gt;     tuples - so no one can use the same tuple declaration in function -<br>
&gt;     they then should declare separate struct type or use @something for<br>
&gt;     such functions. Nobody wants such rule for tuples.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Multi site thing is not a limitation... Is is a proposed rule to say<br>
&gt;     that we are able to be lazy twice without being penalized. Yhe compiler<br>
&gt;     does not like when we define the same thing twice, and thse short form<br>
&gt;     amount to doing what he does not let us do. But because this is about<br>
&gt;     concise and lazy, then the compiler can let us get away with it if we<br>
&gt;     use an annotation that lets it know that &quot;it is not a mistake.. I<br>
&gt;     really dont want to write that enum myself, even though I am using the<br>
&gt;     same abbreviation twice&quot;. Otherwise, the compiler would let us know<br>
&gt;     that the second time could be a mistake because there is already<br>
&gt;     something with the same name...<br>
&gt;<br>
&gt;     But again this is a separate idea from the core notion of a syntax<br>
&gt;     sugaring for writing real enums the lazy (clever) way<br>
&gt;<br>
&gt;     &gt;&gt; On 01.06.2016 19:04, L. Mihalkovic wrote:<br>
&gt;     &gt;&gt; The only problem with this proposal is to consider them ad-hoc<br>
&gt;     enums... If we view them as having nothing ad-hoc about them and the<br>
&gt;     thing to be a simple sugaring exercise, then I think all the opositions<br>
&gt;     on grounds of breaking the language disapear. It still does not mean it<br>
&gt;     should be done if the core team does not like the idea of encouraging<br>
&gt;     laziness, or simply do not like what it makes them look like. No matter<br>
&gt;     what, this type of sugaring exercise has been clearly stated as out of<br>
&gt;     scope for 3.0<br>
&gt;     &gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt; On Jun 1, 2016, at 2:38 PM, Vladimir.S via swift-evolution<br>
&gt;     &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt; wrote:<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt; On 01.06.2016 11:00, Austin Zheng wrote:<br>
&gt;     &gt;&gt;&gt;&gt; Tuples are a structural type, they are described entirely by the fact<br>
&gt;     &gt;&gt;&gt;&gt; that they are a tuple, plus their contained types.<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt; Enum cases are not individual types; that precedent exists nowhere in<br>
&gt;     &gt;&gt;&gt;&gt; Swift. You can&#39;t (yet) build a structural type out of something that<br>
&gt;     &gt;&gt;&gt;&gt; isn&#39;t a type. The fact that you had to propose something like<br>
&gt;     &gt;&gt;&gt;&gt; &quot;AdhocEnumFitFill_2383748&quot; as an autogenerated name for the type<br>
&gt;     &gt;&gt;&gt;&gt; demonstrates the proposal&#39;s weaknesses: a tuple is an ad-hoc type that<br>
&gt;     &gt;&gt;&gt;&gt; describes itself, while an anonymous enum isn&#39;t.<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; Yes, I understand the point about the type of such adhoc enum.<br>
&gt;     &gt;&gt;&gt; The only workaround I can see in this case(if we&#39;d really want to<br>
&gt;     have it in language) if adhoc enum type will be `(.Fit|.Fill)` i.e.<br>
&gt;     textual representation if the declared type. As I understand this also<br>
&gt;     could not be a solution.. I.e. for example<br>
&gt;     `(Int,String,(.Fit|.Fill))-&gt;String`<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; From other point of view, adding such type to typesystem will add<br>
&gt;     some consistence : you can create a function that don&#39;t need definition<br>
&gt;     of separate structure type(tuple will be used) and don&#39;t need separate<br>
&gt;     enum type(ad-hoc enum will be used). I.e. all data the function needs<br>
&gt;     to process could be described in function definition. Today we need to<br>
&gt;     use ugly Bool flags in case we want to achieve the same target.<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt; Now if enum cases were equivalent if they had the same name (like how<br>
&gt;     &gt;&gt;&gt;&gt; &quot;Int&quot; means the same thing no matter what tuple or generic type it is<br>
&gt;     &gt;&gt;&gt;&gt; used in), we&#39;d have a good foundation for a self-describing structural<br>
&gt;     &gt;&gt;&gt;&gt; type. But this isn&#39;t how the existing named enum types work. Why would<br>
&gt;     &gt;&gt;&gt;&gt; it be a good idea to make anonymous enum cases interchangeable by<br>
&gt;     name?<br>
&gt;     &gt;&gt;&gt;&gt; Properties on different types aren&#39;t interchangeable, even if they<br>
&gt;     have<br>
&gt;     &gt;&gt;&gt;&gt; the same type. In fact, no type member that I am aware of is<br>
&gt;     &gt;&gt;&gt;&gt; interchangeable solely on the basis of name. An<br>
&gt;     &quot;ArtistAction.Draw&quot; and<br>
&gt;     &gt;&gt;&gt;&gt; &quot;CowboyAction.Draw&quot; might have the same name, but they mean completely<br>
&gt;     &gt;&gt;&gt;&gt; different things.<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; I don&#39;t think they should be &#39;interchangeable by name&#39;, but just<br>
&gt;     like tuples if you defined adhoc enum with exactly the same cases as<br>
&gt;     ad-hoc enum in function parameters - then they are of the same type.<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; I.e. :<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; func foo(option: (.fit|.fill)) {..}<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; foo(.fit) // .fit is of type  (.fit|.fill) from definition<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; let e : (.fit|.fill) = .fit<br>
&gt;     &gt;&gt;&gt; foo(e) // e is of (.fit|.fill) type, equal to definition<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; but<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; func foo2(option: (.fit|.fill|.other)) {..}<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; foo2(.fit) // ok, here .fit is of (.fit|.fill|.other) type<br>
&gt;     &gt;&gt;&gt; foo2(e) --&gt; Error, e is not of type (.fit|.fill|.other)<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt; Finally, I have to ask: if you are updating your anonymous enum in<br>
&gt;     &gt;&gt;&gt;&gt; multiple places, how much effort have you actually saved over a<br>
&gt;     one-line<br>
&gt;     &gt;&gt;&gt;&gt; enum definition? In fact, tuples are a great example of this: best<br>
&gt;     &gt;&gt;&gt;&gt; practices usually state that they are good for ad-hoc destructuring,<br>
&gt;     &gt;&gt;&gt;&gt; such as retrieving multiple return values from a function or pattern<br>
&gt;     &gt;&gt;&gt;&gt; matching across several values at once, but structs are better<br>
&gt;     used for<br>
&gt;     &gt;&gt;&gt;&gt; almost everything else, since they carry semantic meaning that tuples<br>
&gt;     &gt;&gt;&gt;&gt; don&#39;t.<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; Just the same pros and cons for ad-hoc enums vs enum declaration as<br>
&gt;     for tuples vs struct declaration. Yes can use it with care and you can<br>
&gt;     use it in wrong way.<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; Btw, I feel like this could be very handy to return adhoc enum:<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; func something() -&gt; (.one|.two|.three) {...}<br>
&gt;     &gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt; I hope that clarifies my thoughts on the matter.<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt; Best, Austin<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt; On Jun 1, 2016, at 12:36 AM, Vladimir.S &lt;<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a><br>
&gt;     &lt;mailto:<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>&gt;&gt; wrote:<br>
&gt;     &gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt; On 01.06.2016 9:55, Austin Zheng via swift-evolution wrote:<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; Maybe it&#39;s overkill. My personal opinion is that breaking the<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; symmetry of the language like this (are there any other types of<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; function arguments that cannot be passed as either variable values<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; or literals?) is too much a price to pay. Your library thinks it&#39;s<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; being clever and vends its functions as taking anonymous enum flags,<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; and now there are a bunch of things I can&#39;t do with those functions<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; anymore.<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; A regular enum can be declared in one line anyways:<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; enum ScaleCropMode { case Fit, Fill }<br>
&gt;     &gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt; Why do we have tuples? Struct could be defined by one line `struct<br>
&gt;     &gt;&gt;&gt;&gt;&gt; SomeValue { var x = 0, y = 0 }` ;-) I.e. from my point of view<br>
&gt;     &gt;&gt;&gt;&gt;&gt; developer should decide what he/she wants to use: ad-hoc enum or<br>
&gt;     &gt;&gt;&gt;&gt;&gt; defined enum type *exactly* as now he/she can decide to use the same<br>
&gt;     &gt;&gt;&gt;&gt;&gt; tuples in multiply functions instead of one defined struct type.<br>
&gt;     &gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt; I replied regarding the variable on other message. (In short: I think<br>
&gt;     &gt;&gt;&gt;&gt;&gt; of the same principle as for tuples: you can declare variable `let e:<br>
&gt;     &gt;&gt;&gt;&gt;&gt; (.fill | .fit) = .fill` and use it)<br>
&gt;     &gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; Austin<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; On May 31, 2016, at 11:44 PM, Charles Constant<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:charles@charlesism.com" target="_blank">charles@charlesism.com</a> &lt;mailto:<a href="mailto:charles@charlesism.com" target="_blank">charles@charlesism.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:charles@charlesism.com" target="_blank">charles@charlesism.com</a> &lt;mailto:<a href="mailto:charles@charlesism.com" target="_blank">charles@charlesism.com</a>&gt;&gt;&gt; wrote:<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; It breaks the ability to pass in a variable containing the<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; desired<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; value, rather than the literal value itself.<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; Maybe that&#39;s appropriate? If the caller is not passing in a<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; hardcoded enum case, then that enum is probably general enough<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; that it warrants a normal enum. But there are also situations<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; where the same function is called from several files in the same<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; code-base with different flags. Those are situations where it<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; feels like overkill to clutter up my codebase with separate enums,<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; only used by a single function.<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; On Tue, May 31, 2016 at 9:24 PM, Austin Zheng via swift-evolution<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; I admire the desire of this proposal to increase the readability<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; of code. I&#39;m -1 to the proposal itself, though:<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; - It breaks the ability to pass in a variable containing the<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; desired value, rather than the literal value itself. (Unless you<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; actually want a not-so-anonymous enum type whose definition<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; happens to live in a function signature rather than somewhere<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; you&#39;d usually expect a type definition to live.) - It breaks the<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; ability to store a reference to the function in a variable of<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; function type (ditto). - Almost every time I&#39;ve wanted to use one<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; of these &quot;anonymous enums&quot; in my code, I&#39;ve ended up needing to<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; use that same enum elsewhere. In my experience, &#39;lightweight<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; enums&#39; don&#39;t end up saving much time compared to a full-fledged<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; one.<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; Like Brent said, I have to say no to any proposal that tries to<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; make enums synonyms for numerical values. What happens if you<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; rearrange your anonymous enum cases between library versions? Do<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; you somehow store an opaque case-to-UInt8 table somewhere for<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; every anonymous enum you define for resilience? What happens when<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; people start bringing back terrible C patterns, like doing<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; arithmetic or bitwise ops on the underlying case values? At least<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; you have to try pretty hard as it is to abuse Swift&#39;s enums.<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; Austin<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; On Tue, May 31, 2016 at 8:25 PM, Brent Royal-Gordon via<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt;&gt; wrote:<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; And the obvious answer is you can have up to 255 of these babies<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; for the anonymous enum type, and be able to pass numerical<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; equivalents UInt8 with compile time substitution. That the<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; ad-hoc enumeration is basically a syntactic shorthand for UInt8,<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; with an enforced upper bound compile time check simplifies<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; everything including switch statements.<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; If I wanted a language like that, I&#39;d be writing C, not Swift.<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; -- Brent Royal-Gordon Architechies<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________ swift-evolution<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; mailing list <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________ swift-evolution<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; mailing list <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________ swift-evolution<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; mailing list <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;     &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;     &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt;&gt;<br>
&gt;     &gt;&gt;&gt; _______________________________________________<br>
&gt;     &gt;&gt;&gt; swift-evolution mailing list<br>
&gt;     &gt;&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;     &gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;     &gt;&gt;<br>
&gt;     _______________________________________________<br>
&gt;     swift-evolution mailing list<br>
&gt;     <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;     <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
</blockquote></div></div>