Thoughts about D

[Jonathan M Davis]

On Friday, December 01, 2017 03:43:07 Adam D. Ruppe via Digitalmars-d wrote:
> On Friday, 1 December 2017 at 03:23:23 UTC, Walter Bright wrote:
> > 26 bytes of inserted Bloaty McBloatface code and 15 bytes of
>
> > data. My proposal:
> I suggest we break up the -release switch into different options.
> I never, never use -release since it implies no bounds checking.
> But if we wanted small asserts, we'd ideally like -slimassert
> perhaps to change that behavior without killing arrays too.

It only implies no bounds checking in @system code, though obviously, if
you're not marking code with @safe or simply want the bounds checking to be
enabled in @system code, then using -release isn't something that you're
going to want to do. Regardless, I don't think that it makes sense for
-release to imply any kind of enabling of assertions, since a lot of folks
write assertions with the idea that they're only going to be enabled in
debug builds, and sometimes, what's being asserted isn't cheap. So, we do
need to either have a different flag to enable stripped down assertions in a
release build or have some sort of argument to -release that controls what
it does (which has been suggested for the DIP related to controlling
contracts). And once you're talking about enabling some kind of assertion in
a release build, that begs the question of whether contracts and invariants
should be included. Pretty quickly, it sounds like what -release does isn't
appropriate at all, and a debug build with optimizations enabled makes more
sense - though it would still need a flag of some kind to indicate that you
wanted the stripped down assertions.

- Jonathan M Davis