<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 Jan 27, 2016, at 5:18 PM, Jordan Rose 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="">Hi, everyone. This isn't <i class="">exactly</i> a language feature, but it's something that would benefit from the idea pool and bikeshedding that happens on the list. Simply put, what's the name of this feature?<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">#if os(OSX)</div><div class="">#if swift(>=3.0)</div><div class="">#if DEBUG</div></blockquote><br class=""><div class="">And what's this command-line option? (not that most people are invoking Swift on the command line)</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">swift -DDEBUG main.swift</div></blockquote><br class=""><div class="">---</div><div class=""><br class=""></div><div class="">The <a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/compiler-control-statement" class="">Swift Programming Language book</a> and the compiler diagnostics aren't quite consistent here:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">#if: "configuration block" (compiler), "build configuration statement" (book)</div><div class="">(the condition): "build configuration expression" (compiler), "build configuration" (book)</div><div class="">os(…) and arch(…): "target configuration expression" (compiler), "platform testing function" (book)</div><div class="">swift(>=…): "version requirement" (compiler), (not yet in book)</div><div class=""><br class=""></div><div class="">-D flag: "specifies one or more build configuration options"</div></blockquote><div class=""><br class=""></div><div class="">On top of this, there's another problem: the term "build configuration" has long been used by Xcode to refer to "Debug", "Release", etc—a different mode of compilation that manifests itself as different build settings. Having two different concepts with the same name is never a great idea, and Xcode's feature definitely has seniority here.</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class="">Some things to keep in mind for this feature:</div><div class=""><br class=""></div><div class="">- All conditions are (currently) compile-time conditions.</div><div class="">- Code in the non-compiled block still has to parse…except if the predicate is "swift(>=…)", for obvious reasons.</div><div class="">- All conditions are boolean-valued predicates; the ones set on the command line are options (present or absent), not macros.</div><div class=""><br class=""></div><div class="">Here's my proposed names to get the discussion started:</div><div class=""><br class=""></div><div class="">- "Conditional Compilation Block" for the whole construct (from the #if to the #endif and everything in between).</div><div class="">- "Conditional Compilation Directive" for the #if line (and #elseif line). Not sure if the #endif line applies.</div><div class="">- "Conditional Compilation Expression" for the condition of a #if.</div><div class="">- "Platform Compilation Features" for all the function-like predicates (including "swift(>=…)", even though that's special.</div></div></div></blockquote><div><br class=""></div><div>I don’t love the name “Features” , but I don’t have an obviously better suggestion off hand.</div><div><br class=""></div><div>Why do you want to combine the version requirement with the other predicates? I would think the special behaviour was worth calling out.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- "Custom Compilation Features" for all the user-defined options.</div><div class="">- "marks a custom compilation feature as present" as the --help text for -D.</div><div class=""><br class=""></div><div class="">…but I'd be happy if someone comes up with something better. (And I'd like feedback on if any of these names are problematic in some other way.)</div></div></div></blockquote><div><br class=""></div><div>+1 overall, this seems like a nice cleanup.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Thanks, all,</div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. Since this is only changing diagnostics and the book, I don't think it needs to go through the full evolution process, but someone else from the core team can correct me.</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>