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

[Dmitri Gribenko]

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

Dmitri

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



-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/