On Sat, 5 Feb 2005 17:27:07 -0800, Walter <newshound@digitalmars.com> wrote:
> I'm not saying you would advocate "fixing" the code this way. I don't either. Nobody would. I am saying that this is often how real programmers will fix it. I know this because I see it done, time and again, in response to compilers that emit such error messages. This kind of code is a disaster waiting to happen. No compiler will detect it. It's hard to pick up on a code review. Testing isn't going to pick it up. It's an insidious, nasty kind of bug. It's root cause is not bad programmers, but a compiler error message that encourages writing bad code.

No, its root cause *is* bad programmers.  A good programmer would not
interpret a missing-return error as an encouragement to mindlessly
stick a "return 0;" in the code, but rather an indication that
there's a code path that isn't properly terminated.  Now, it may be
the case that there are a lot of bad programmers out there, but that
doesn't make it the compiler's fault[1], nor does it mean that those who
would not commit this particular offense should have a useful
compile-time diagnostic denied to them.

What if the error message were "missing return statement or assert(0)" rather than just "missing return statement"?

> Instead, having the compiler insert essentially an assert(0); where the missing return is means that if it isn't a bug, nothing happens, and everyone is happy.

The person reading the code isn't happy when he can't tell whether it was an error that simply hadn't been caught in testing (or that was, but he's unsure of which piece of code to blame), or an intentional implicit assert(0).

The person who mainly gets missing-return errors for cases where there really should be a return but it was forgotton (such as when a function is changed from returning void to returning non-void, or a non-void-returning stub function that was left completely empty) is also not happy that he doesn't find the bug until run-time testing.

> If it is a bug, the assert gets tripped, and the programmer *knows* it's a real bug that needs a real fix,

Only if it shows up in testing.  If it's on a rare but known-possible execution path, where the programmer would have realized the need for a proper return statement (or other action) if he had been shown an error message, the bug gets found later.

-Scott

[1] This isn't in the same class as array bounds checking, garbage collection, etc. where the programmer mistakes that they avoid arise out of overlooking something (which all humans do from time to time); in this case, the programmer looked directly at the problem and decided to do something stupid.

sai wrote:

> I would say, -release is more intutive and self-explainatory, its just a matter of documentation to specify what -release does. 

Okay, so -release is "intuitive" and "self-explanatory" - but you'll have to read the docs to find out what it does ? Does not compute :-)
I find "-debug -release" to be a rather weird combination of DFLAGS ?

But the first is just a version, and the second means to drop contracts
(including pre-conditions, invariants, post-conditions and assertions)
and also array-bounds and switch-default checks. Thus it is OK to mix.

And of course, the -O and -g are somewhat related to debug vs. release
too - but in D that's something else: optimization and debug symbols
(neither of which is affected by settings for "-debug" or "-release")

--anders

PS.
GDC has already added two flags, that are not found in DMD:
-fbounds-check (for ArrayBounds) and -femit-templates (needed
for template workarounds, on compilers without one-only linkage)

> 14) list classes with high cyclomatic complexity measurements

Interesting idea but it could be hard to compute and hard to know what to do
about it. Can you see a code analysis program saying something like "Your
code is too complicated. Make it simpler."
Or are you hinting at a dangerous problem involving cyclic references?

> 15) list classes with getters/setters only

why is this one a problem?

> 16) rant on use of uninstantiated objects

I like it - a lint with attitude. For those C++ programmers who don't read the documenation carefully enough.

> 17) highlight ill-named identifiers

Style-guides would be nice - as long as they are very customizable and optional!

> ...
> wait a sec.  is there anyone passionate enough to launch the dlint
> project?

If it's still not done by the time MinWin gets settled (still many months) then I will definitely give it a shot. I could use a dlint ASAP.

On Sat, 5 Feb 2005 17:46:37 -0800, Walter <newshound@digitalmars.com> wrote:
> What you're advocating sounds very much like how compile time warnings work
> in typical C/C++ compilers. Is this what you mean?

<snip>

To me, there seems to be one important difference between this proposition and the current compile time warnings of a c/c++ compiler.

That difference is that the D compiler is going to do something about it, eg.

switch(a) {
case 1:
case 2:
}

a C compiler might say, "Warning: no default case". The D compiler is going to add a default case which throws an exception if triggered, now, can't it also issue a notification of what it has done eg. "Note: default case added".


To me, this behaviour cannot be called a 'warning' but either the literal definition of the word:
  http://dictionary.reference.com/search?q=warning
or by the behaviour we are all used to.


According to the web pages, the reason for removing warnings..

"No Warnings

D compilers will not generate warnings for questionable code. Code will either be acceptable to the compiler or it will not be. This will eliminate any debate about which warnings are valid errors and which are not, and any debate about what to do with them. The need for compiler warnings is symptomatic of poor language design."

This new imagined behaviour does not violate the above paragraph.


As mentioned previously this new behaviour allows you to catch the bug in the compile phase and before the testing phase.

Regan

Anders_F_Bj=F6rklund?= says...
>Okay, so -release is "intuitive" and "self-explanatory" - but you'll have to read the docs to find out what it does ? Does not compute :-) I find "-debug -release" to be a rather weird combination of DFLAGS ?

Yes, -release means ..... it is a release version with all contracts (including pre-conditions, invariants, post-conditions and assertions) etc etc turned off, quite self explainatory to me !!

Now, to know what all types of checks, contracts, pre-conditions, invariants etc are supported by the compiler, see its documentation.

>But the first is just a version, and the second means to drop contracts (including pre-conditions, invariants, post-conditions and assertions) and also array-bounds and switch-default checks. Thus it is OK to mix.

I didn't say it is OK to mix. I usually don't put a -debug switch
along with -release switch. Mixing both switches doesn't make sense either.

Sai

"sai" <sai_member@pathlink.com> wrote in message news:cu65me$27i4$1@digitaldaemon.com...
> Anders_F_Bj=F6rklund?= says...
>>Okay, so -release is "intuitive" and "self-explanatory" - but you'll have to read the docs to find out what it does ? Does not compute :-) I find "-debug -release" to be a rather weird combination of DFLAGS ?
>
> Yes, -release means ..... it is a release version with all contracts
> (including
> pre-conditions, invariants, post-conditions and assertions) etc etc
> turned off,
> quite self explainatory to me !!

I think the original issue under debate, sadly largely ignored since, is whether contracts (empty clauses elided, of course), should be included in a 'default' release build. I'm inexorably moving over to the opinion that they should, and I was hoping for opinions from people, considering the long-term desire to turn D into a major player in systems engineering

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opslsqnpdr23k2f5@ally...
> On Sat, 5 Feb 2005 17:46:37 -0800, Walter <newshound@digitalmars.com> wrote:
>> What you're advocating sounds very much like how compile time
>> warnings  work
>> in typical C/C++ compilers. Is this what you mean?
>
> <snip>
>
> To me, there seems to be one important difference between this proposition  and the current compile time warnings of a c/c++ compiler.
>
> That difference is that the D compiler is going to do something about it,  eg.
>
> switch(a) {
> case 1:
> case 2:
> }
>
> a C compiler might say, "Warning: no default case". The D compiler is going to add a default case which throws an exception if triggered, now,  can't it also issue a notification of what it has done eg. "Note: default  case added".
>
>
> To me, this behaviour cannot be called a 'warning' but either the
> literal  definition of the word:
>   http://dictionary.reference.com/search?q=warning
> or by the behaviour we are all used to.
>
>
> According to the web pages, the reason for removing warnings..
>
> "No Warnings
>
> D compilers will not generate warnings for questionable code. Code will  either be acceptable to the compiler or it will not be. This will  eliminate any debate about which warnings are valid errors and which are  not, and any debate about what to do with them. The need for compiler  warnings is symptomatic of poor language design."
>
> This new imagined behaviour does not violate the above paragraph.
>
>
> As mentioned previously this new behaviour allows you to catch the bug in  the compile phase and before the testing phase.
>
> Regan

Sounds like a pretty excellent compromise to me!!

On Sat, 5 Feb 2005 20:26:43 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:

<snip>

>     Camp A want behaviour X to be done automatically by the compiler
>     Camp B want behaviour Y to be done automatically by the compiler. X
> and Y are incompatible, when done automatically.

Not true, assuming:

X == compile time warning/error of the fault
Y == auto-insert of code to cause runtime error for fault.

As described the compiler can do both.

<snip>

Regan

On Mon, 7 Feb 2005 09:32:19 +1100, Matthew wrote:

> "sai" <sai_member@pathlink.com> wrote in message news:cu65me$27i4$1@digitaldaemon.com...
>> Anders_F_Bj=F6rklund?= says...
>>>Okay, so -release is "intuitive" and "self-explanatory" - but you'll have to read the docs to find out what it does ? Does not compute :-) I find "-debug -release" to be a rather weird combination of DFLAGS ?
>>
>> Yes, -release means ..... it is a release version with all contracts
>> (including
>> pre-conditions, invariants, post-conditions and assertions) etc etc
>> turned off,
>> quite self explainatory to me !!
> 
> I think the original issue under debate, sadly largely ignored since, is whether contracts (empty clauses elided, of course), should be included in a 'default' release build. I'm inexorably moving over to the opinion that they should, and I was hoping for opinions from people, considering the long-term desire to turn D into a major player in systems engineering

I'm thinking as I write here, so I could be way off ...

Isn't the idea of contracts just a mechanism to assist *coders* locate bugs during testing. And by 'bugs', I mean behaviour that is not documented in the program's (business) requirements specifications. As distinct from runtime handling of bad data or unexpected situations.

If so, then by the time you build a final production version of the application, all the testing is completed. And thus contracts can be removed from the final release. However, you might keep them in for a beta release.

Bad data and unexpected situations should be still addressed by exceptions and/or simple messages, designed to be read by an *end* user and not only the developers.

-- 
Derek
Melbourne, Australia
7/02/2005 9:39:01 AM

Matthew wrote:

> I think the original issue under debate, sadly largely ignored since, is whether contracts (empty clauses elided, of course), should be included in a 'default' release build. I'm inexorably moving over to the opinion that they should, and I was hoping for opinions from people, considering the long-term desire to turn D into a major player in systems engineering

I just don't think contracts has anything to do with release vs. debug ?

For instance, I had to build a non-release version of the Phobos lib
just to make it check the runtime contracts in my own debugging builds.
I though that pure debugging code was to be put in debug {} blocks ?
And that the contracts *could* remain, even in released versions...

Array-bounds and switch-default are probably OK to strip for release.
Maybe stripping asserts and contracts in release builds is standard
procedure, but it would be more straight-forward if called -contract ?
(which could be a "subflag" that is triggered to 0 by -release, but)

Or maybe I am just mixing up exceptions versus contracts, as usual...
http://research.remobjects.com/blogs/mh/archive/2005/01/11/232.aspx

Even so, having a libphobos-debug.a version has helped me catch a few.
(i.e. for debugging builds I use -lphobos-debug, -lphobos for release)

--anders