[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