True. I was thinking to much in the content of the stdlib only but with a
builtin you can get things optimized away.
On Tue, Mar 15, 2016 at 9:22 AM Dmitri Gribenko <griboz...@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 <shaw...@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@swift.org> wrote:
> >>
> >>
> >>
> >> On Mar 14, 2016, at 2:04 PM, Dmitri Gribenko <griboz...@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@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 <griboz...@gmail.com>*/
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
