On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
On Friday, 1 August 2014 at 08:21:28 UTC, Kagamin wrote:
On Thursday, 31 July 2014 at 21:29:59 UTC, Sean Kelly wrote:
So effectively, any factor occurring at runtime. If I create
a
library, it is acceptable to validate function parameters
using
assert() because the user of that library knows what the
library
expects and should write their code accordingly. That's fair.
He should, but what if he doesn't and the library is phobos or
druntime (which are compiled in release mode)? BTW, druntime
can't use enforce and doesn't verify its input.
Druntime uses contracts and asserts in places. Which are of
course removed because we ship only a "release" build. Once
again, the worst naming for a compiler switch ever. What I
really want is a way to ship release and non-release builds
(ie. checked and unchecked) and have the proper one chosen at
link time based on build flags. Basically toss the -defaultlib
and -debuglib and replace it with -checkedlib and -uncheckedlib.
Well, to be fair, it's pretty standard practice to remove all
assertions in release builds in other languages. If anything,
leaving them in is highly abnormal. Sure, there are reasons to do
it, but most folks don't. So, while I can see why you don't like
the switch being called -release, it's behavior matches what most
people would do for release builds. If anything, I think that
-debug is the switch that's problematic, because people think
that it's the opposite of release when it's completely unrelated
(and useless for most code, because most people aren't going to
be using debug blocks - especially if they don't understand the
-debug switch).
But we probably would be better off if none of the switches had
names like -release or -debug so that folks actually had to
figure out what they did before using them rather than simply
assuming that one is for release builds and the other is for
debug builds.
- Jonathan M Davis
