[swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

Dmitri Gribenko gribozavr at gmail.com
Tue Mar 15 11:21:35 CDT 2016

A function can absolutely can do that, if it is implemented using a
builtin known to the optimizer.


On Tue, Mar 15, 2016 at 9:20 AM, Shawn Erickson <shawnce at gmail.com> wrote:
> You would likely want to ensure debug related code could be optimized away /
> or not be included in release builds. I am not sure how a function would
> achieve that.
> On Tue, Mar 15, 2016 at 9:15 AM Erica Sadun via swift-evolution
> <swift-evolution at swift.org> wrote:
>> On Mar 14, 2016, at 2:04 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> 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.
>> Dmitri
>> Could the debug build test take the form of a standard non-private
>> function then
>> instead of _isDebugAssertConfiguration()? If the test is limited to
>> methods,
>> introducing #if-style tests would be ugly.
>> How likely or easy is it for me to reframe the request for testing for
>> debug to be as
>> simple as:
>> `if debugBuild() {...}`
>> with `debugBuild` vended by the standard library instead of as a build
>> configuration test?
>> -- E
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-evolution mailing list