On Monday, 6 April 2015 at 08:30:38 UTC, Kagamin wrote:
On Monday, 6 April 2015 at 06:25:14 UTC, Brad Anderson wrote:
You made that change back in 2009. https://issues.dlang.org/show_bug.cgi?id=3407

-release used to turn off all bounds checking. Andrei wanted it to stay in safe code at least so you added -noboundscheck to appease those that wanted it off even in safe code then you made it do bounds checking by default in safe code even if -release was specified. There was never an option to turn on bounds checking for all code in release mode (not until -boundscheck=on was added). Whenever we'd discuss -noboundcheck on the forums you'd have 5 people with 5 different ideas about what that option did. It was very confusing.

IIRC about a year ago, when the new option was introduced, -release was changed to keep bounds checking everywhere... ok, looks like it was Andrei's belief, which never made it into the source :)

When -boundscheck was added? Nah, it didn't make any changes to the default bound checking behavior and there was never any proposal to change the default behavior. -boundscheck was just adding more flexibility than the existing option.

I'm not sure why Andrei had the impression that bounds checking was enabled universally on release builds. Probably just misremembering the outcome of issue 3407. Perhaps there was a conversation later where it was decided to make that change but the change never made it into source.

I know some people are opposed but I still think there should be several variants of phobos/druntime included in the release with various flags enabled/disabled. Not every permutation but a reasonable set. -debug, -release, -release with no inlining (do we still not enable inlining anyway?) and with full bounds checking, contracts, asserts, etc.). I don't think requiring end users to rebuild phobos/druntime themselves is a reasonable expectation. Microsoft had 8 variants of their runtime available until they dropped the single threaded offering recently (now down to 4 variants).

Reply via email to