<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="">William and Alex, thanks for the reply. I’m aware of the compile-time option. My post was originally to ask if the difference between constant and closure initialization for constants was intentional (and likely to remain) or just a temporary idiosyncrasy. I find #ifdef to be ugly and like prefer to avoid it unless absolutely necessary. Thanks for the <div class="">head up on Active Compilation Conditions William, I wasn’t aware of it. Anything I can do to avoid the Build Settings tab is more than welcome.</div><div class="">-d<br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 19, 2016, at 1:57 PM, William Sumner <<a href="mailto:prestonsumner@me.com" class="">prestonsumner@me.com</a>> 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 19, 2016, at 5:50 AM, David Goodine via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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="">Hey all,<div class=""><br class=""></div><div class="">I don’t know if this is really an ‘evolution’ topic per se, and I’m not on Swift Dev, but thought someone here could shed some light on this.</div><div class=""><br class=""></div><div class="">Often when developing code, if I need create mode switches (constant Bools) so that I can move back and forth between different features/implementations for testing, developing experimental features, migration, etc. Currently if I write the following:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">let useFoo = true</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class="">if useFoo {</font></div><div class=""><font face="Courier" class="">// Foo code</font></div><div class=""><font face="Courier" class="">} else {</font></div><div class=""><font face="Courier" class="">// Non-Foo code</font></div><div class=""><font face="Courier" class="">}</font></div><div class=""><br class=""></div><div class="">I will get compiler warnings either way that there’s unreachable code based on the value of useFoo. That makes sense in most cases, but in some cases I need to leave the code as is for a while, and I hate leaving long-standing compiler warnings in production code. (If it’s yellow, you need to pay attention to it.) So I poked around and discovered that if I use the following declaration of useFoo, the warnings go away.</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">let useFoo = { return true }()</font></div><div class=""><br class=""></div><div class="">So, the question is, is this intentional? The compiler could certainly ascertain that useFoo will always be true and carry out the same dead code detection as for the first declaration. If this isn’t intentional, and the compiler may at some point optimize away the closure and trigger dead code warnings, I might come up with a proposal that there is some idiom that allows one to do the above without the warnings. I’m really not a fan of #define (because it’s just butt-ugly in such a beautiful language), but its existence is unavoidable for some cases. </div><div class=""><br class=""></div><div class="">And, as I write this, I realized I haven’t tried declaring useFoo as var, but I expect that would trigger a warning that useFoo is not modified and should be defined by let. I think this is a use case that, for practical purposes, should be covered to allow this type of evolution of code without generating warnings. If the current behavior is intentional and going to stay, then that’s probably the best solution.</div><div class=""><br class=""></div><div class="">-d</div></div></div></blockquote></div><br class=""><div class="">You should use Active Compilation Conditions to create flags for conditional compilation you can check with #if. If you’re not yet using Xcode 8, you can manually define the flags under the Other Swift Flags build setting (e.g., -DUSEFOO).</div><div class=""><br class=""></div><div class="">Preston</div></div></div></blockquote></div><br class=""></div></div></body></html>