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

[Dmitri Gribenko]

On Tue, Mar 15, 2016 at 9:31 AM, Erica Sadun <erica at ericasadun.com> wrote:
> I would like to update my draft proposal to introduce a test for debug configurations using a public function
> rather than a build configuration test.
>
> * Would the stdlib team be open to that?

No objections from me.

> * What would be an appropriate name?  `debugConfiguration`? `debugBuild`? `isDebugBuild`? `isDebugConfiguration`?

It seems like this API can be a property.  "isDebug..." is a good
start, but a debug what?  Build?  Build configuration?  I remember
Jordan was trying to rename the "build configuration" feature -- I
don't know where he arrived though.

OTOH, if you are willing to allow implementation complexity, you can
use '#if'-style conditional compilation, and allow arbitrary internal
and private APIs in the #if blocks.  Just as long as uses are guarded
with same, we should be fine.  I'm not sure if we want that user
model, though.

Dmitri

>
> -- E
>
>
>> On Mar 15, 2016, at 10:21 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>
>> 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>*/
>



-- 
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>*/