July 08, 2008
"Sean Kelly" <sean@invisibleduck.org> wrote in message news:g4vvtg$2237$1@digitalmars.com...

> And regarding this particular issue, it's not uncommon to have unused function parameters.  And while C++ allows them to be left out:
>
> void fn( int ) {}
>
> D does not.  A warning for this would be terribly annoying.

Are you sure about that?  Cause that compiles and runs in D.


July 08, 2008
== Quote from Jarrett Billingsley (kb3ctd2@yahoo.com)'s article
> "Sean Kelly" <sean@invisibleduck.org> wrote in message news:g4vvtg$2237$1@digitalmars.com...
> > And regarding this particular issue, it's not uncommon to have unused function parameters.  And while C++ allows them to be left out:
> >
> > void fn( int ) {}
> >
> > D does not.  A warning for this would be terribly annoying.
> Are you sure about that?  Cause that compiles and runs in D.

Really?  It didn't used to :-)


Sean
July 08, 2008
Nick Sabalausky wrote:
> Ok, so the different warnings should be able to be turned on and off. If you don't agree with a particular type of warning then you turn it off. That's the nice thing about warnings as opposed to errors: they're optionally letting you know about certain conditions that you might want to be aware of, and they do it without changing, redefining, or otherwise affecting the language itself.

That situation exists today for C++ compilers, and it's not so good. You have, as I mentioned previously, n factorial different languages instead of 1. Portability becomes a problem. Confusion about whether the code should compile or not reigns.

>> If it was in the compiler, it would inhibit development of static analysis tools,
> Can you elaborate on how this would happen?

It's the same reason why "m4" never caught on as a C preprocessor, despite being vastly superior, and despite everyone who wanted a better CPP being told to use m4.


>> and would confuse the issue of what was correct D code.
> 
> Anything that generates a warning instead of an error is by definition valid code. If it wasn't valid it would generate an error instead of a warning.

That's true, but it is not what happens in the real world with warnings. I've dealt with warnings on C/C++ compilers for 25 years, and the practice is very different from the theory.
July 09, 2008
Nick Sabalausky wrote:
>> The problem with warnings is that if there are n warnings, there are essentially n factorial different versions of the language.
> I really don't see how this is, unless every compiler always has "treat warnings as errors" permanently enabled with no way to disable. That's like saying that using different lint tools, or different settings within a the same lint tool constitutes different versions of the same language, and then claiming that means we shouldn't use lint tools.

If you have 10 warnings, each independently toggled on or off, then you have 10 factorial different languages. The difference between lint and a compiler is people know lint is not a compiler and do not worry about lint's complaints. Warnings in the compiler are treated, in reality, like programming errors.

>>  If you're faced with compiling someone else's code (like you downloaded it off the internet and have to compile it because it only is distributed as source) and warnings go off, is that a bug in the code or not? What do you do?
> By definition, that's not an error.

I know, but that is NOT how they are perceived. People wonder if they downloaded it right, or if they downloaded the right version, they wonder if they should complain about it, they wonder if the program will work properly if compiled. It sucks.

>> Some shops have a "thou shall compile with warnings enabled, and there shall be no warning messages."
> That's a management problem, not a compiler design problem.

Management of programming teams is an important issue. There are a number of characteristics in D that try to make it easier for managers to manage the programmers. These are based on my conversations with many managers about the kinds of problems they face. I don't agree that these issues should be ignored and dismissed as just a management problem.

>> Those kind of things tend to interfere with the beauty of the code, and since they are not necessary to the program's logic, they tend to confuse and misdirect the maintenance programmer (why is this variable pointlessly referenced here? Why is this unreachable return statement here? Is this a bug?)
> Thus comments.

I don't agree with relying on comments to make up for a language design that encourages confusing and misleading code to be written.


> Like I've said, compiler warnings are essentialy a built-in lint tool. I see no reason to think of them any other way. 

I think you and I have had very different experiences with warnings!
July 09, 2008
is "walter bright" the name for a group of high experienced software developers and managers - or is an escaped us-army expert-system- experiment

because sometimes i am realy shocked how perfect your ideas fits developers(managers) daily needs

and i hope its not to hard for you to describe people, who are years behind your experience - and normaly don't understand the(or your) problem domain - why your ideas are better...

you are my how-it-should-work-brain-brother
its like a memo of my thinking each time i read your comments
thx very much for writing them down :-)

July 09, 2008
On Mon, 07 Jul 2008 09:23:15 +0100, Don <nospam@nospam.com.au> wrote:

>
> I agree. Unfortunately, there's a problem with the 'optional' warnings we have in DMD right now. They are not optional for libraries. If a library generates warnings, then it is not usable by anyone who wants to compile with warnings enabled.
>
> I'd love to see the warnings tightened up so that they can become bugs.
>

That is questionably a flaw in the way D processes libraries. But the same flaw as in C++.
If your include file has warnings you have to surpress them when using the library.
Presumably if you use .di files (created/compiled with warnings switched off) this won't
happen?

Regards,

Bruce.
July 09, 2008
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g51k8s$102f$1@digitalmars.com...
> The difference between lint and a compiler is people know lint is not a compiler and do not worry about lint's complaints. Warnings in the compiler are treated, in reality, like programming errors.
>

Ahh, now this appears to be the root of our differing opinions on this. I think I understand your reasoning behind this now, even though I still don't agree with it.

It sounds like (previously unknown to me) there's a rift between the reality of warnings and the perceptions that many programmers (excluding us) have about warnings. As I understand it, you consider it more important to design around common perceptions of warnings, even if they're mistaken perceptions (such as warnings, by definition, not actually being errors). My disagreement is that I consider it better to design around the realities, and use a more education-based approach (I don't necessarily mean school) to address misperceptions. Is this a fair assessment of your stance, or am I still misunderstanding?

If this is so, then our disagreement on this runs deeper than just the warnings themselves and exists on more of a "design-values" level, so I won't push this any further than to just simply note my disagreement.


July 09, 2008
"Nick Sabalausky" <a@a.a> wrote in message news:g51qgu$1f63$1@digitalmars.com...
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g51k8s$102f$1@digitalmars.com...
>> The difference between lint and a compiler is people know lint is not a compiler and do not worry about lint's complaints. Warnings in the compiler are treated, in reality, like programming errors.
>>
>
> Ahh, now this appears to be the root of our differing opinions on this. I think I understand your reasoning behind this now, even though I still don't agree with it.
>
> It sounds like (previously unknown to me) there's a rift between the reality of warnings and the perceptions that many programmers (excluding us) have about warnings. As I understand it, you consider it more important to design around common perceptions of warnings, even if they're mistaken perceptions (such as warnings, by definition, not actually being errors). My disagreement is that I consider it better to design around the realities, and use a more education-based approach (I don't necessarily mean school) to address misperceptions. Is this a fair assessment of your stance, or am I still misunderstanding?
>
> If this is so, then our disagreement on this runs deeper than just the warnings themselves and exists on more of a "design-values" level, so I won't push this any further than to just simply note my disagreement.

I'd also like to note one other thing...Umm, this might come across sounding harsh, so please understand I don't in any way intend it as any sort of personal or professional disrespect/insult/sarcasm/etc.:

It's just that the way I've always felt about lint tools is, I've always seen lint tools as a sign of popular languages and compilers doing an insufficient job of catching easily-overlooked programming mistakes. (For instance, if I were going to use a language that allows implicit variable declarations (makes hidden mistakes easy), *and* there was no way to prevent the compiler/interpreter from remaining silent about it when it happened (a mere band-aid in the case of the implicit declaration problem, but a very welcome band-aid nonetheless), then I would grunble about it and try to find a lint tool that plugged that bug-hole. This, of course, goes back to the "good/bad redundancy in lanugage design" point that you've made.)


July 09, 2008
Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g51k8s$102f$1@digitalmars.com...
>> The difference between lint and a compiler is people know lint is not a compiler and do not worry about lint's complaints. Warnings in the compiler are treated, in reality, like programming errors.
>>
> 
> Ahh, now this appears to be the root of our differing opinions on this. I think I understand your reasoning behind this now, even though I still don't agree with it.
> 
> It sounds like (previously unknown to me) there's a rift between the reality of warnings and the perceptions that many programmers (excluding us) have about warnings. As I understand it, you consider it more important to design around common perceptions of warnings, even if they're mistaken perceptions (such as warnings, by definition, not actually being errors). My disagreement is that I consider it better to design around the realities, and use a more education-based approach (I don't necessarily mean school) to address misperceptions. Is this a fair assessment of your stance, or am I still misunderstanding?
> 
> If this is so, then our disagreement on this runs deeper than just the warnings themselves and exists on more of a "design-values" level, so I won't push this any further than to just simply note my disagreement. 

I think Walter is right here too.  With Microsoft compilers warnings are so copious that they become almost useless.  They warn about piles of trivial things that only have a remote possibility of being a bug.   So you end up just ignoring them, and in that case they might as well not be there.  It's just annoying.

I think the problem is that the compiler writers have this attitude that they can be "helpful" by warning about anything that possibly could be a bug, even if it's going to have 100 times more false positives than real hits.  That's not a good way to do warnings.

By making warnings either off or fatal like D, you force the compiler writers to actually think long and hard about whether the warning they're thinking to add is really so likely to be a bug that they should force the user to change the code.  If it's fairly likely that the coder actually knows what they're doing, then that really doesn't justify the compiler issuing the warning.  A lint tool fine, but not the compiler.

+1 votes for Walter  :-)

--bb
July 09, 2008
Bruce Adams wrote:
> On Mon, 07 Jul 2008 09:23:15 +0100, Don <nospam@nospam.com.au> wrote:
> 
>>
>> I agree. Unfortunately, there's a problem with the 'optional' warnings we have in DMD right now. They are not optional for libraries. If a library generates warnings, then it is not usable by anyone who wants to compile with warnings enabled.
>>
>> I'd love to see the warnings tightened up so that they can become bugs.
>>
> 
> That is questionably a flaw in the way D processes libraries. But the same flaw as in C++.

It's even worse in D, though, because with warnings switched on the library won't compile at all.

> If your include file has warnings you have to surpress them when using the library.

And D has no way to do that.

> Presumably if you use .di files (created/compiled with warnings switched off) this won't
> happen?

That's an interesting idea. That might well work.

> 
> Regards,
> 
> Bruce.