<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 5 Jul 2016, at 12:47, Charlie Monroe via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is mentioned in Gabriel's proposal:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Implement a native&nbsp;.cases&nbsp;static var for all&nbsp;enumerations <b class="">without associated values</b></blockquote></div><div class=""><br class=""></div><div class="">But as has been mentioned in the discussion, this was mentioned by Brent:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">In previous discussions, the core team specifically asked that this be <b class="">opt-in</b> so that types which don't want it don't need to "pay" for it.<br class=""></blockquote><br class=""></div></div></div></blockquote></div><br class=""><div class="">Looking at the previous discussions, this kind of functionality belongs as part of reflection (once we have a mature reflection API). If you are reflecting a type that is completely known to the compiler (e.g. a concrete value-type, such as a struct or enum), it should be able to statically optimise it.</div><div class=""><br class=""></div><div class="">This is a commonly-enough requested feature that I would like to do it before the reflection API (there’s no public roadmap yet, but I don’t think it’s even under consideration for Swift 4). OTOH, I’m not sure if it makes sense to implement it in hacky way with compiler-generated constants and then replace it once we have a stable ABI.</div><div class=""><br class=""></div><div class="">Probably best to wait for the Swift 4 roadmap discussion and to see what the plans for reflection actually are. So I’m taking back my +1, sorry.</div><div class=""><br class=""></div><div class="">Karl</div></body></html>