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 <[email protected]> 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 > <[email protected]> wrote: >> >> >> >> On Mar 14, 2016, at 2:04 PM, Dmitri Gribenko <[email protected]> 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 >> [email protected] >> 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 <[email protected]>*/ _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
