[swift-evolution] Renaming "Build Configuration"
jtbandes at gmail.com
Thu Jan 28 12:45:26 CST 2016
I'm used to the name "directive" from C preprocessor nomenclature, but I
think it would best be used for all of #available, #selector, and #line, in
addition to #if/#else/#endif.
Maybe "#if" is a "conditional directive", and "os(...) && swift(...)" is
simply its condition.
-D "Defines" something (a flag). Perhaps it "defines a flag such that the
'#if flag' condition is true".
On Wed, Jan 27, 2016 at 5:18 PM, Jordan Rose via swift-evolution <
swift-evolution at swift.org> wrote:
> Hi, everyone. This isn't *exactly* 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?
> #if os(OSX)
> #if swift(>=3.0)
> #if DEBUG
> And what's this command-line option? (not that most people are invoking
> Swift on the command line)
> swift -DDEBUG main.swift
> The Swift Programming Language book
> <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/compiler-control-statement> and
> the compiler diagnostics aren't quite consistent here:
> #if: "configuration block" (compiler), "build configuration statement"
> (the condition): "build configuration expression" (compiler), "build
> configuration" (book)
> os(…) and arch(…): "target configuration expression" (compiler), "platform
> testing function" (book)
> swift(>=…): "version requirement" (compiler), (not yet in book)
> -D flag: "specifies one or more build configuration options"
> 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.
> Some things to keep in mind for this feature:
> - All conditions are (currently) compile-time conditions.
> - Code in the non-compiled block still has to parse…except if the
> predicate is "swift(>=…)", for obvious reasons.
> - All conditions are boolean-valued predicates; the ones set on the
> command line are options (present or absent), not macros.
> Here's my proposed names to get the discussion started:
> - "Conditional Compilation Block" for the whole construct (from the #if to
> the #endif and everything in between).
> - "Conditional Compilation Directive" for the #if line (and #elseif line).
> Not sure if the #endif line applies.
> - "Conditional Compilation Expression" for the condition of a #if.
> - "Platform Compilation Features" for all the function-like predicates
> (including "swift(>=…)", even though that's special.
> - "Custom Compilation Features" for all the user-defined options.
> - "marks a custom compilation feature as present" as the --help text for
> …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.)
> Thanks, all,
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution