<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Maybe it's overkill. My personal opinion is that breaking the symmetry of the language like this (are there any other types of function arguments that cannot be passed as either variable values or literals?) is too much a price to pay. Your library thinks it's being clever and vends its functions as taking anonymous enum flags, and now there are a bunch of things I can't do with those functions anymore.<div class=""><br class=""></div><div class="">A regular enum can be declared in one line anyways:</div><div class=""><br class=""></div><div class="">enum ScaleCropMode { case Fit, Fill }</div><div class=""><div class=""><br class=""></div><div class="">Austin </div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 31, 2016, at 11:44 PM, Charles Constant <<a href="mailto:charles@charlesism.com" class="">charles@charlesism.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">> <span style="font-size:13px" class=""> It breaks the ability to pass in a variable containing the desired value, rather than the literal value itself.</span><div class=""><span style="font-size:13px" class=""><br class=""></span></div><div class=""><span style="font-size:13px" class="">Maybe that's appropriate? If the caller is</span> not passing in a hardcoded enum case, then that enum is probably general enough that it warrants a normal enum. But there are also situations where the same function is called from several files in the same code-base with different flags. Those are situations where it feels like overkill to clutter up my codebase with separate enums, only used by a single function. </div><div class=""><br class=""></div><div class=""><span style="font-size:13px" class=""><br class=""></span></div><div class=""><span style="font-size:13px" class=""><br class=""></span></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 31, 2016 at 9:24 PM, Austin Zheng via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I admire the desire of this proposal to increase the readability of code. I'm -1 to the proposal itself, though:<div class=""><br class=""></div><div class="">- It breaks the ability to pass in a variable containing the desired value, rather than the literal value itself. (Unless you actually want a not-so-anonymous enum type whose definition happens to live in a function signature rather than somewhere you'd usually expect a type definition to live.)</div><div class="">- It breaks the ability to store a reference to the function in a variable of function type (ditto).</div><div class="">- Almost every time I've wanted to use one of these "anonymous enums" in my code, I've ended up needing to use that same enum elsewhere. In my experience, 'lightweight enums' don't end up saving much time compared to a full-fledged one.</div><div class=""><br class=""></div><div class="">Like Brent said, I have to say no to any proposal that tries to make enums synonyms for numerical values. What happens if you rearrange your anonymous enum cases between library versions? Do you somehow store an opaque case-to-UInt8 table somewhere for every anonymous enum you define for resilience? What happens when people start bringing back terrible C patterns, like doing arithmetic or bitwise ops on the underlying case values? At least you have to try pretty hard as it is to abuse Swift's enums.</div><div class=""><br class=""></div><div class="">Austin</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 31, 2016 at 8:25 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> And the obvious answer is you can have up to 255 of these babies for the anonymous enum type, and be able to pass numerical equivalents UInt8 with compile time substitution. That the ad-hoc enumeration is basically a syntactic shorthand for UInt8, with an enforced upper bound compile time check simplifies everything including switch statements.<br class="">
<br class="">
</span>If I wanted a language like that, I'd be writing C, not Swift.<br class="">
<span class=""><font color="#888888" class=""><br class="">
--<br class="">
Brent Royal-Gordon<br class="">
Architechies<br class="">
</font></span><div class=""><div class=""><br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></body></html>