On 8/1/2014 12:47 PM, Tofu Ninja wrote:
> Having your augment consistently dismissed by "I see no difference" or "That is
> misuse" is frustrating to say the least.

I repeatedly gave detailed rationales for that.

On 8/1/14, 5:16 PM, eles wrote:
> On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
>> On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
>
>> The debug and the release build may be subjected to different input
>> and hence traverse different traces of abstract states. It is not
>> valid to say that an assertion will never fail just because it hasn't
>> failed yet.
>
> Yes, but is the same for the C apps. There, you have no assertion in the
> release build, the release build is optimized (I imagine very few would
> use -O0 on it...), then the sefault happens.
>
> Good luck with the debugger and find the bug in the source code....
>
> This is why debug builds exist, to reproduce problems and to investigate
> the bugs.

The problem is then trying to copy everything C and C++ does and putting it in D...

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

On Friday, 1 August 2014 at 20:30:19 UTC, Daniel Gibson wrote:
> Am 01.08.2014 22:16, schrieb eles:
>> On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
>>> On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
>>
>>> The debug and the release build may be subjected to different input
>>> and hence traverse different traces of abstract states. It is not
>>> valid to say that an assertion will never fail just because it hasn't
>>> failed yet.
>>
>> Yes, but is the same for the C apps. There, you have no assertion in the
>> release build, the release build is optimized (I imagine very few would
>> use -O0 on it...), then the sefault happens.
>>
>
> But there checks are not optimized away because of assert.
> assert(x != NULL);
> if(x != NULL) { ... }
> in C the if check won't be optimized away in NDEBUG builds, in equivalent D code it would, because the assert would make the compiler assume that x will never be NULL at that point.

And why is that a problem? By definition, if an assertion fails, your code is in an invalid state, and by compiling out assertions, you're basically assuming that they all pass, so you're code's already screwed if the assertion would have failed had it been compiled in. I don't see how having the compiler then use that assertion for optimizations really costs you anything. Worst case, it just makes already invalid code more invalid. You're screwed regardless if the assertion would have failed. And if it would have succeeded, then you just got an efficiency boost thanks to the assertion.

Thinking about it, I'm actually wondering if I should use assertions _more_ so that the compiler might be able to do better optimizations in -release. The extra cost in non-release builds could be worth that extra boost in -release, and as far as correctness goes, it never hurts to have more assertions.

- Jonathan M Davis

On Fri, Aug 01, 2014 at 09:42:06PM +0000, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
[...]
> 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.
[...]

Great. So let's rename all of dmd's command-line options to -a, -b, -c, -d, -e, -f, ... (in arbitrary order). As long as we document it all, it will work just perfectly fine, right? After all, it *does* force users to *really* know what each option does. :-D


T

-- 
Gone Chopin. Bach in a minuet.

On 08/01/2014 11:50 PM, Jonathan M Davis wrote:
> ... as far as correctness goes, it never hurts to have more assertions.

Pipe dream.

On 8/1/2014 2:50 PM, Jonathan M Davis wrote:
> Thinking about it, I'm actually wondering if I should use assertions _more_ so
> that the compiler might be able to do better optimizations in -release.

I think this will be a productive strategy once this gets implemented in optimizers.

Of course, using them effectively will not be easy unless one is willing to understand how data flow analysis works and is willing to examine the generated code.

On Friday, 1 August 2014 at 16:52:00 UTC, Daniel Murphy wrote:
> "Sean Kelly"  wrote in message news:tngnltzwxprebpbcdkgm@forum.dlang.org...
>
>> 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.
>
> While shipping a debug version of druntime would be useful, I think the real problem is that checking preconditions is disabled by the callee!  If preconditions are violated, the error is in the caller, and checking should be enabled based on the application's flags.

Exactly.  When the user builds with -release set, DMD should link
the unchecked libphobos.  And without this flag it should link
the checked build.  So the user choice of whether to use
contracts extends at least to the standard library.

Also, I don't like the -debuglib option because when a user sets
the debug flag in their build, what they want is to debug their
own code, not the standard library.  While it's sometimes useful
to have debug symbols in the standard library you're linking
against, it's basically never useful to have internal debug code
enabled in the standard library because even if there's a bug in
that library, you can't do anything about it.  And presumably the
library has been tested against that debug code anyway.

On 8/1/2014 3:34 PM, Sean Kelly wrote:
> Also, I don't like the -debuglib option because when a user sets
> the debug flag in their build, what they want is to debug their
> own code, not the standard library.  While it's sometimes useful
> to have debug symbols in the standard library you're linking
> against, it's basically never useful to have internal debug code
> enabled in the standard library because even if there's a bug in
> that library, you can't do anything about it.  And presumably the
> library has been tested against that debug code anyway.

It's mainly useful for having a library with symbolic debug info in it, which makes it easier to work with in a symbolic debugger.

On 8/1/2014 7:33 AM, Kagamin wrote:
> Nobody cares about intermediate files,

I do because it influences build speed, which is a major feature of D.