<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jun 7, 2016, at 2:49 PM, L Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">This is my favorite approach (assuming it's technically feasible) as it preserves the limitation that the enumerations are scoped strictly to the function but can be referenced outside of it.</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">It allows type inference for dropped prefixes because the compiler can unambiguously match the ad hoc enumeration type to the parameter.</li><li class="">It introduces the possibility (for Matthew) of assigning a value to a variable.</li><li class="">It preserves the notion that an ad-hoc enum makes syntactic and semantic sense only with respect to its use in a function/method parameter list.</li></ul></div><div class=""><br class=""></div><div class="">If an enumeration needs wider semantics, it should be a standalone type, whether as a nested or not.</div><div class=""><br class=""></div><div class="">Reiterating the reasons for this pitch:</div><div class=""><ul class=""><li class="">It streamlines coding, eliminating standalone enumeration types that are used only once</li><li class="">It enables you to see all enumeration options at a glance, and can be reflected in the QuickHelp documentation</li><li class="">It encourages `switch` coding over `if-then-else` coding so each case is labeled and self documenting</li><li class="">It pushes semantics to the call-site in a way that simple Boolean flags cannot: `operation: .Fit` means more than `shouldFill: false`.</li></ul></div><div class="">I'd like to know at this point whether Hooman's approach is even technically feasible, although it's horrible timing the Tuesday before WWDC to get core team feedback on anything.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">There is currently a draft circulating for the removal of @noreturn. If memory serves, I think there was another annotation recently removed. There was also the recent change of dynamicType into something like type(of:).. all these changes have one thing in common: they are streamlining the language, chasing the magic out and replacing it with the careful application of a few simple principles. @_exposed would IMVHO be a setback: </div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">it would introduce a new special annotation</li><li class="">the annotation would have very little chance of being anything but a one of, used for a single scenario</li></ul></div><div class=""><br class=""></div><div class="">Scala went that way years ago, going left right and center, with all sort of great ideas. In the end, for the past few Scala Days Oderski has been going on stage explaining why a language with too many clever tricks is in nobody’s interest.</div><div class=""><br class=""></div></div><span style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">if and when they decide to focus on small syntactic sugaring enhancements (akin to javac's Project Coin), then they have an easy way to make it happen without any magic or special rules.</span></div></blockquote></div><br class=""><div class="">What appeals to me is scoping the enumeration to the function: Semantic sugar that creates a global</div><div class=""><br class=""></div><div class="">function.parameterName.enum {case ... }</div><div class=""><br class=""></div><div class="">You had suggested using semantic sugar in a different way, did you not? </div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></body></html>