[swift-evolution] Renaming "Build Configuration"

[Jacob Bandes-Storch]

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"
> (book)
> (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
> -D.
>
> …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,
> Jordan
>
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/fb4eca62/attachment.html>