"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu3tn3$292$1@digitaldaemon.com...
> I would agree, for reasons of legacy breaking, were it not that D is pre-1.0. Since I'm coming to believe more and more that PwC should _not_ be considered a debug only thing, I think it should be the default.
>
> Naturally, I'm looking at this from the perspective of large commercial systems. For simple utilities, I'd be adding -contracts=off to my makefiles, and be content with that decision.
>
> Walter, may we have it on by default? (and divorce from debug?)
>
> Please. I'll be polite. Honest, ...., mate! :-)

It is on by default. All -release does is turn it off. You could compile with:

dmd -O foo

and you'll get debug off, contracts on, optimization on.

-debug turns on the debug() statements. -g turns on the "generate symbolic debug info". These are all independent of each other.

The reason -inline is a seperate switch is that sometimes inlining can make things slower, debugging can be difficult with inlining happening, and profiling is more accurate with inlining off.

Sorry, mate, I've given up - I'll just have to content myself with writing Imperfect D with all the good amo you're providing - and am about to take the family out for some retail therapy. Ah, D.J.'s pesto, there's nothing like it ..... once you've tasted it, anything that comes out of a bottle might as well be cat vomit.

As for our doomed debate, I'll leave this parting shot: you've ignored the two most salient points of the debate recently made, namely the effect that missing error harbinging will have on the mindset - will it cause people to (mis-)add more return 0's than they would have anyway? - and the issue of having the compiler require what Derek wisely suggests. Alas, it appears that you are wont to do so.

Dr Cassandra Bigboy

P.S. For all the people who've joined the NG since the middle of last year, and have not seen such stag-rutting battles between Walter and myself (and others), you should know that despite (what I believe) are his stunning misapprehensions, I have a higher (technical and good-egg-edness) regard for big-W than almost anyone I know, famous or just quietly-good-at-their-job. Maybe it's because of that that I find his wrongness so affronting? Kind of like finding out your mother farts. ;)


"Walter" <newshound@digitalmars.com> wrote in message news:cu44i1$739$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu3v58$3c3$1@digitaldaemon.com...
>> A maintenance engineer is stymied by *both*
>> forms, and confused contrarily: the first looks like a bug but may
>> not
>> be, the second is a bug but doesn't look like it. The only form that
>> stands up to maintenance is something along the lines of what Derek's
>> talking about:
>>
>>     int foo(CollectionClass c, int y)
>>     {
>>         foreach (Value v; c)
>>         {
>>             if (v.x == y)
>>                 return v.z;
>>         }
>>
>>         throw logic_error("This function has encountered a situation
>> which contradicts its design and/or the design of the software within
>> which it resides");
>>
>>         return 0;
>>     }
>
> From a C/C++ perspective, you're right, this is the only correct
> solution.
> From a D perspective, however, I submit that the first example is not
> confusing. There is no falling off the end in D functions, as an
> exception
> would be thrown. The only returns that can happen are explicitly there
> with
> return statements. The maintenance engineer will know this as surely
> as he
> knows that after an assert(p) that p is not null. I agree this is a
> different way of thinking about the code, that coming from a solid
> C/C++
> background it might be a bit off-putting.
>
>> This is what I also do in such cases, and I believe (and have
>> witnessed)
>> it being a widely practiced technique.
>
> Yes, and I've written magazine articles and done lectures pushing
> exactly
> that. It's what one has to do with C/C++.
>
>>You're
>> keen to mould D with a view to catering for, or at least mitigating
>> the
>> actions of,  the lowest common denominators of the programming gene
>> pool.
>
> I've seen this kind of error written by experts, not just the lowest
> common
> denominator. If D cannot prevent an error, it should try to mitigate
> the
> damage.
>
>>Yet you seem decidely uninterested in addressing the concerns of
>> large scale and/or commercial and/or large-teams and/or long-lasting codebases. How can this attitude help D to prosper?
>
> I have to disagree with this. Many features of D are the result of
> many long
> conversations with program development managers. They need positive
> mechanisms in the language to prevent or at least mitigate the effects
> of
> common, very human, programming mistakes. C and C++ are seriously
> deficient
> in this area. That you disagree with the efficacy of one the solutions
> does
> not at all mean I am uninterested. A very large part of D is providing
> support for writing robust code.
>
>> Your measure adds an indeterminately timed exception fire, in the
>> case
>> that a programmer doesn't add a return 0. That's great, so far as it
>> goes. But here's the fly in your soup: what's to stop them adding the
>> return 0?
>
> Absolutely nothing. But as I wrote before, if he's looking at fixing
> the
> code after the exception fired, he knows he's dealing with a bug that
> needs
> fixing. In the case of the compiler error message, there is not
> necessarilly
> a bug there, so the easy temptation is to throw in a return of some
> arbitrary value. Is that bad programming technique? Absolutely. Does
> it
> happen anyway? Yes, it does. I've been in code review meetings and
> listened
> to the excuses for it. Those kinds of things are hard to pick up in a
> code
> review, so removing the cause of it and trying to mitigate the damage
> is of
> net benefit.
>
> Let's put it this way, here are the choices (numbers pulled out of
> dimension
> X):
>
> 1) A bug catching feature that 90% of the time will cause the
> programmer to
> write correct code, but 10% of the time will result in code that has
> an
> insidious, nasty, hard to reproduce & find bug.
>
> 2) A bug catching feature that 70% of the time will cause the
> programmer to
> write correct code, but the 30% that get it wrong results in code that
> when
> it fails, fails cleanly, in an easy to reproduce, find and therefore
> fixable
> manner.
>
> It's a judgement call, not dogma. I'd rather have (2), and I believe
> that
> (2) is better for the long term success of a code base. I do not like
> (1), b
> ecause the penalties of such bugs, even though they are less frequent,
> are
> so severe they overshadows everything else.
>
> 

On Sat, 5 Feb 2005 17:27:07 -0800, Walter wrote:

> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:cu25p2$1jbc$1@digitaldaemon.com...
>> Walter says: if it's compile time, programmers will patch it without thinking.  That's bad.  So let's use runtime.
> 
> That's essentially right.
> 
> I'll add one more example to the ones you presented:
> 
> int foo(Collection c, int y)
> {
>     foreach (Value v; c)
>     {
>         if (v.x == y)
>             return v.z;
>     }
> }

And the coder probably should have done some more like ...

 int foo(Collection c, int y)
 {
     foreach (Value v; c)
     {
         if (v.x == y)
             return v.z;
     }
     throw LogicException( "#42. In routine 'foo' the collection contained
an impossible value '" ~ toString(y) ~ "'");
 }


> By the nature of the program I'm writing, "y" is guaranteed to be within c. Therefore, there is only one return from the function, and that is the one shown. But the compiler cannot verify this. You recommend that the compiler complain about it.

You use the word 'complain', whereas I'd tend you the phrase 'alert the coder to a potential problem'.

> I, the programmer, knows this can never happen, and I'm
> in a hurry with my mind on other things and I want to get it to compile and
> move on, so I write:
> 
> int foo(CollectionClass c, int y)
> {
>     foreach (Value v; c)
>     {
>         if (v.x == y)
>             return v.z;
>     }
>     return 0;
> }

For which the peer review team should give you a smack the hand for. Most commercial coders do not work in a vacuum. The lone coder is always going to be a minority. Most coders have multiple others reading and critiquing there code long before it gets into commercial release.

> 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.

Is that 'real' as opposed to 'unreal'? Or are you implying the 'real' also implies the majority of commercial coders working in a typical organisation that cares about quality.

>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.

Why is that? Common checklist items for functions include ...

  ** Does every possible return value meet the contract for the function?
  ** Does the default return value meet the function contract?
  ** Does the default return value imply an error situation, and if so,
does the caller respond to the error value?
  ** Is the default return value also one of the possible non-default
values, and if so, is it allowed for in the function requirements.

> Testing isn't going to pick it up.

Testing *may not* pick it up. Sometimes it does.

>It's an insidious, nasty kind of bug.

Amen to that brother.

>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. 'Bad' in the sense that they are
not responsible coders. The compiler message would remind responsible
coders to do the right thing; to others it just pisses them off.

> 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. If it is a bug, the assert gets tripped, and the programmer *knows* it's a real bug that needs a real fix, and he won't be tempted to insert a return of an arbitrary value "because it'll never be executed anyway".

Actually, it's more likely that it is not the programmer who finds out about it, but one of his customers. Then the programmer *and* the customer is not so happy. What is so wrong about trying to find problems as early as possible? Why wait til the customer rings you up to complain?

> This is the point I have consistently failed to make clear.

You have made your point very clear. I really, really , really do understand your point of view. I just don't agree with you that is useful.

-- 
Derek
Melbourne, Australia

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:cu40vq$4ne$1@digitaldaemon.com...
> I don't know where to jump into this thread so I'll jump here. Walter,
would
> it be possible to get a "lint" program that flags dubious constructs? I'd
> like to working something like that into the D emacs mode so that typical
> errors can be flagged as the source code is written instead - but at the
> user's request.
> At work we use a tool like this called mlint - obviously based on the old
> lint program and it does wonders for cleaning up code and suggesting more
> efficient constructs etc. We have it integrated into all of our MATLAB
> editor tools so that you just hit a button and it highlights all the lines
> with recommendations and what the recommendations are. I hope that given
D's
> lack of preprocessor and simpler syntax a dlint program would be able to generate some very useful recommendations.

I don't think it would be hard to morph the D front end code into a lint. Such a program could also be configurable by the end user to enforce the local coding style guide. I think it could be a valuable tool. Anyone looking for a D project to do? <g>

"Walter" <newshound@digitalmars.com> wrote in message news:cu454v$7km$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu3tn3$292$1@digitaldaemon.com...
>> I would agree, for reasons of legacy breaking, were it not that D is
>> pre-1.0. Since I'm coming to believe more and more that PwC should
>> _not_
>> be considered a debug only thing, I think it should be the default.
>>
>> Naturally, I'm looking at this from the perspective of large
>> commercial
>> systems. For simple utilities, I'd be adding -contracts=off to my
>> makefiles, and be content with that decision.
>>
>> Walter, may we have it on by default? (and divorce from debug?)
>>
>> Please. I'll be polite. Honest, ...., mate! :-)
>
> It is on by default. All -release does is turn it off. You could
> compile
> with:
>
> dmd -O foo
>
> and you'll get debug off, contracts on, optimization on.
>
> -debug turns on the debug() statements. -g turns on the "generate
> symbolic
> debug info". These are all independent of each other.
>
> The reason -inline is a seperate switch is that sometimes inlining can
> make
> things slower, debugging can be difficult with inlining happening, and
> profiling is more accurate with inlining off.

Cool. Sounds like the _only_ thing to do is rename the misnomer "-release" to "-nocontracts". Can we have that, and forestall all the wasted mental cycles for people who have to learn what it really means?

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu3vu0$3sv$1@digitaldaemon.com...
> Walter was one of the reviewers of IC++, and never expressed reservations on this section.
>
> Was I wrong?

It is the conventional wisdom, and all other things being equal, it's correct. It makes an implicit assumption that all bugs are equally bad. I'll refer you to the tradeoff I mentioned in the other posting, about preferring a lightweight bug in greater quantity to a heavyweight bug in lesser quantity.

"Derek" <derek@psych.ward> wrote in message news:1iq2ryvz6s0l9.id90ayeemth4$.dlg@40tude.net...
> You have made your point very clear. I really, really , really do understand your point of view. I just don't agree with you that is useful.

It's fair to disagree. I just want to get across the reasoning, so the decision doesn't look arbitrary. Now that I've succeeded in that, I'll retire for the moment from this debate <g>.

Here's a suggestion that /might/ help: are you, Walter, familiar with AOP at all? If so, you might consider treating such things as part of "cross-cutting concerns", where

a) a "point-cut" is declared, by the programmer, to add code to those non-void-returning functions which don't actually end with a return statement.

b) the code generated at the end of a function would thus be an "advice". One which has been explicitly provided by the programmer, rather than by the compiler.

Here's a little blurb on AOP, via Google: http://www.onjava.com/pub/a/onjava/2004/01/14/aop.html

- Kris


In article <cu44i1$739$1@digitaldaemon.com>, Walter says...
>
>
>"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu3v58$3c3$1@digitaldaemon.com...
>> A maintenance engineer is stymied by *both*
>> forms, and confused contrarily: the first looks like a bug but may not
>> be, the second is a bug but doesn't look like it. The only form that
>> stands up to maintenance is something along the lines of what Derek's
>> talking about:
>>
>>     int foo(CollectionClass c, int y)
>>     {
>>         foreach (Value v; c)
>>         {
>>             if (v.x == y)
>>                 return v.z;
>>         }
>>
>>         throw logic_error("This function has encountered a situation
>> which contradicts its design and/or the design of the software within
>> which it resides");
>>
>>         return 0;
>>     }
>
>From a C/C++ perspective, you're right, this is the only correct solution. From a D perspective, however, I submit that the first example is not confusing. There is no falling off the end in D functions, as an exception would be thrown. The only returns that can happen are explicitly there with return statements. The maintenance engineer will know this as surely as he knows that after an assert(p) that p is not null. I agree this is a different way of thinking about the code, that coming from a solid C/C++ background it might be a bit off-putting.
>
>> This is what I also do in such cases, and I believe (and have witnessed) it being a widely practiced technique.
>
>Yes, and I've written magazine articles and done lectures pushing exactly that. It's what one has to do with C/C++.
>
>>You're
>> keen to mould D with a view to catering for, or at least mitigating the actions of,  the lowest common denominators of the programming gene pool.
>
>I've seen this kind of error written by experts, not just the lowest common denominator. If D cannot prevent an error, it should try to mitigate the damage.
>
>>Yet you seem decidely uninterested in addressing the concerns of
>> large scale and/or commercial and/or large-teams and/or long-lasting codebases. How can this attitude help D to prosper?
>
>I have to disagree with this. Many features of D are the result of many long conversations with program development managers. They need positive mechanisms in the language to prevent or at least mitigate the effects of common, very human, programming mistakes. C and C++ are seriously deficient in this area. That you disagree with the efficacy of one the solutions does not at all mean I am uninterested. A very large part of D is providing support for writing robust code.
>
>> Your measure adds an indeterminately timed exception fire, in the case that a programmer doesn't add a return 0. That's great, so far as it goes. But here's the fly in your soup: what's to stop them adding the return 0?
>
>Absolutely nothing. But as I wrote before, if he's looking at fixing the code after the exception fired, he knows he's dealing with a bug that needs fixing. In the case of the compiler error message, there is not necessarilly a bug there, so the easy temptation is to throw in a return of some arbitrary value. Is that bad programming technique? Absolutely. Does it happen anyway? Yes, it does. I've been in code review meetings and listened to the excuses for it. Those kinds of things are hard to pick up in a code review, so removing the cause of it and trying to mitigate the damage is of net benefit.
>
>Let's put it this way, here are the choices (numbers pulled out of dimension
>X):
>
>1) A bug catching feature that 90% of the time will cause the programmer to write correct code, but 10% of the time will result in code that has an insidious, nasty, hard to reproduce & find bug.
>
>2) A bug catching feature that 70% of the time will cause the programmer to write correct code, but the 30% that get it wrong results in code that when it fails, fails cleanly, in an easy to reproduce, find and therefore fixable manner.
>
>It's a judgement call, not dogma. I'd rather have (2), and I believe that
>(2) is better for the long term success of a code base. I do not like (1), b
>ecause the penalties of such bugs, even though they are less frequent, are
>so severe they overshadows everything else.
>
>

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu45td$89b$1@digitaldaemon.com...
> Cool. Sounds like the _only_ thing to do is rename the misnomer "-release" to "-nocontracts". Can we have that, and forestall all the wasted mental cycles for people who have to learn what it really means?

The original idea behind -release was to not require the DMD programmer to learn a bunch of arcane weird switches (look at any C++ compiler!), there'd be a switch that would make it "just work".

Looks like I failed :-(

"Walter" <newshound@digitalmars.com> wrote in message news:cu4c88$ecu$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cu45td$89b$1@digitaldaemon.com...
>> Cool. Sounds like the _only_ thing to do is rename the misnomer "-release" to "-nocontracts". Can we have that, and forestall all the wasted mental cycles for people who have to learn what it really means?
>
> The original idea behind -release was to not require the DMD
> programmer to
> learn a bunch of arcane weird switches (look at any C++ compiler!),
> there'd
> be a switch that would make it "just work".
>
> Looks like I failed :-(

Yes, it's that real world again. Better to have several switches which tell the absolute truth about what they each do than a few umbrella switches that mislead, don't you think? :-)