[swift-evolution] Renaming "Build Configuration"
jtbandes at gmail.com
Thu Jan 28 13:01:19 CST 2016
How about "hashtags"? ;-)
On Thu, Jan 28, 2016 at 10:49 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> Hm. I wasn't considering #available and #selector to be "directives"
> because they don't "direct" the compiler to do anything; they're "just"
> expressions with special effects. The existing "#line" would be a
> directive, though.
> On Jan 28, 2016, at 10:45, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
> 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