[swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test
Dany St-Amant
dsa.mls at icloud.com
Thu Mar 17 21:23:05 CDT 2016
> Le 14 mars 2016 à 16:04, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> a écrit :
>
> On Mon, Mar 14, 2016 at 11:57 AM, Erica Sadun via swift-evolution
> <swift-evolution at swift.org> wrote:
>> https://gist.github.com/erica/d20639b409fe1b318c0e
>>
>> Feedback solicited. Thanks, -- Erica
>>
>> Introducing a Debug Build Configuration Test
>>
>> Proposal: SE-00XX
>> Author(s): Erica Sadun
>> Status: TBD
>> Review manager: TBD
>>
>> Introduction
>>
>> This proposal introduces a configuration test for debug builds.
>>
>> This proposal was discussed on-list in the Introducing a Debug Build
>> Configuration Test thread.
>>
>> Motivation
>>
>> Developers are used to including code specific to debug builds in their
>> projects. Having a debug configuration test is an industry standard option.
>> Under the current version of Swift you must add a command-line flag using -D
>> <#flag#> (e.g. -D debug) and test in-code (#if debug), there's no consistent
>> system-supplied way to differentiate code meant only for debug builds.
>>
>> Detail Design
>>
>> This proposal adds #if config(debug) to test for debug builds.
>>
>> #if config(debug)
>> // code for debug builds only
>> #endif
>
> Hi Erica,
>
> Based on Joe's rationale that you are quoting, I think the intent is
> that we want to restrict this directive to be statement-level only.
> The API vended by a module should not be affected by the build mode.
Is this really worst than wrapping some API section with #if os(OSX)?
Not that I am for API which change based on build setting, but a #if in the first
column is easy to spot as something conditionally compiled in.
Dany
More information about the swift-evolution
mailing list