On Thursday, 10 April 2014 at 19:48:16 UTC, Steven Schveighoffer
wrote:
On Thu, 10 Apr 2014 15:38:37 -0400, Tommi
<[email protected]> wrote:
On Thursday, 10 April 2014 at 18:13:30 UTC, Steven
Schveighoffer wrote:
As a general rule, first profile, then optimize.
Exactly. I profile the difference between running with and
without bounds checking. If the difference is deemed
negligible for our purposes, we don't spend time and money in
carefully optimizing away bound checks that are analyzed to be
reasonably safe to remove. You need the compiler flag to
potentially save you all the trouble.
This is a weak argument. If you need to optimize, do it. Bounds
checking is one of a thousand different possible explanations
for slow code. You have to weigh that remote possibility with
the threat of accidentally/inadvertently neutering @safe.
You also exaggerate the cost of changing a few @safe to
@trusted. The cost of adding the -noboundscheck flag to the
build system in the right places may be just as significant.
-Steve
Changing druntime and phobos is a much bigger deal than a flag.
In a perfect world I'd agree with you completely but as a
practical matter I think the flag needs to stay.
There is also an issue of marketing (as annoying as it is). This
problem is reminiscent of the garbage collector argument against
D. For far too many people D is a no-go simply because it has a
garbage collector. In reality the garbage collector isn't a
problem for the overwhelming majority of use cases but many
people will never use the language for this reason.
If someone wants to be reckless and turn off the compiler adding
bounds checking in @safe code D should allow them to. It is a
systems programming language, after all. Being allowed to be
reckless and even stupid is a hallmark of that. That doesn't mean
we can't guide people to make smart choices though. -release will
always do bounds checking on @safe functions.
How about a compromise? A stern warning is given whenever someone
compiles with -boundscheck=none (-noboundscheck). One that
stresses they should benchmark before commit to turning it off
and that it should only be used as a last resort.
