Don wrote:
> (2) In DMD, the signed/unsigned error (as it exists today) really is garbage. I've had to introduce incorrect code (via casts) into both Tango and Phobos in order to satisfy it.

I agree that looks pretty damning.

superdan wrote:
> i don't think assert(0); is cool. in a release build it disappears 

Actually it does not disappear in release mode.  assert(0) and assert(false) are always active.  For better or worse, it's treated as a special case.

--bb

Bill Baxter Wrote:

> superdan wrote:
> > i don't think assert(0); is cool. in a release build it disappears
> 
> Actually it does not disappear in release mode.  assert(0) and assert(false) are always active.  For better or worse, it's treated as a special case.

thanks. ow that sucks goat balls. i finally explained to myself the weird shit that happened to me a couple months ago. why the special case???

Walter Bright wrote:
> Don wrote:
>> (2) In DMD, the signed/unsigned error (as it exists today) really is garbage. I've had to introduce incorrect code (via casts) into both Tango and Phobos in order to satisfy it.
> 
> I agree that looks pretty damning.

It's bugzilla 1257.

Bill Baxter wrote:
> superdan wrote:
>> i don't think assert(0); is cool. in a release build it disappears 
> 
> Actually it does not disappear in release mode.  assert(0) and assert(false) are always active.  For better or worse, it's treated as a special case.
> 
> --bb

What's "worse" about it? I think it actually makes sense.

The reason normal asserts are not put in release mode is for performance reasons: so that the program doesn't waste time processing the assert condition, when it could evaluate to true, and not generate an exception.
But when a program reaches an assert(false) it would always throw, and you have a bug, so I see no reason for it to be removed in release code. Unless you want your program to try to keeping going nonetheless (instead of throwing), but I'm not sure that's a good idea, although I guess it could work in some cases.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> The reason for treating warnings as errors when warnings are enabled is so that, for a long build, they don't scroll up and off your screen and go unnoticed.

Dear gods... These are the kind of comments that make me cringe deep inside, and honestly worry me about the future of D. :(

Looking at the output of a compiler in a console is a thing of the past. It's fraking obsolote. It's only done when you're hobbying or toying with the language. No one who does serious development is going to do that. What you do is use an IDE with a minimum of intelligence, that presents to you the warnings in a sensible way. Here's an example from CDT:
http://www-128.ibm.com/developerworks/library/os-eclipse-ganymede/

Before some people here say they don't use an IDE, but instead use <editor foo with syntax highlighting and little more than that> and are fine with it, well, ask yourselves, are you doing any serious development, or just toying around? If you were in a multi-team, 6+ months project, working with such tools, do you think you would perform the same as the same team, with a proper toolchain?
Head my words: you wouldn't. Thinking otherwise is a nuisance.

And it's even worse if you're Walter. Basing such language/tool design issues on outdated notions is a danger to D's development. And it's not just the "looking at compiler output in console", there are plenty of other cases of this mentality.
Walter, you need to shed some of your outdated notions of the software development process and think of the *modern* (present and future) development models that exist, or D will risk heavily retarded adoption (or even failure).

I'm dead serious and I want to "record" this message for future reference, especially if things don't go well (which may not be obvious though).


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> 
> I'll draw on my 25 years of experience with warnings to answer this.
> 
> If you turn warnings on, then you want to see them and presumably deal with them. If you don't deal with them, then they persist every time you compile, and either they get very irritating and you fix them anyway, or you develop a blind spot for them and never see the ones you do want to fix.
> 
> Piping the output into a file and then perusing it manually looking for warning statements is never going to happen. Complex builds tend to produce a lot of output, and poking through it looking for warnings every time you build is not practical. Changing your build process to point out warnings is the same thing as the compiler treating them as errors, except it's extra work for the build master.
> 

Of course it's not going to happen. Cause manually looking at the compiler output is plain ridiculous. See my other post for details.

> Trying to educate your programmers into doing extra work to deal with warnings that scroll off the screen is a lost cause.
> 

Again, anyone who firmly believes that trying to look at console output is even a worthy cause to begin with (lost or not), is living in the past.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> Nick Sabalausky wrote:
>> I don't suppose there's any chance of DMD getting a warning for variables/arguments that are declared but never accessed? Just today alone there's been two bugs I spent 10-30 minutes going nuts trying to track down that turned out to be variables I had intended to use but forgot to. 
> 
> The problem with unused variable warnings is they are annoying when you're developing code in an iterative manner. They get in the way when you're commenting out sections of code to try and isolate a problem. They can be a problem when using "version" and "static if" statements.
> 
> So, why not just turn off the warnings?
> 
> The problem with warnings is that if there are n warnings, there are essentially n factorial different versions of the language. 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?
> 

You have a distorted notion of warnings. Warnings are not errors (and by corollary are not "optional errors" also). They are simply messages which indicate some "strange" situations in code, which suggest some attention from the developer (now or in the future).
That's why other compilers have an *option* such as "treat-warnings-as-errors". If they were errors, they wouldn't need that option, cause they would already be treated as errors (cause they would *be* errors...), lol. :(

You (Walter) and other people, may be inclined to disagree, especially if you are heavily biased torwards C++, where warnings, like you said, have been used for *things that should have been errors*, and have created this whole messed up and confused situations, and scenarios where people think C++ code should compile without errors, etc., etc.. But that is just a scenario arising from C++ fucked-up-ness.

If you (and others) still don't agree, which you probably won't, then let's not argue semantics, and just call this notion of warnings that I defined before as "cautions".
_ With this in mind, what's wrong with the compiler generating messages (and just messages, not errors) for certain suspicious code situations, such as unused variables? Just that, what do you say? _


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bill Baxter wrote:
> 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.
> 

But Visual Studio had the option to disable *specific* warnings either globally (in the IDE), or locally (in source code with pragma statements). So in my experience with VS C++, even though I did find several types of warnings which were fairly useless, I simply disabled those kinds of warnings globally, keeping all the others. So I don't see a problem here.

> 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

And because I don't see a problem, I also don't find the need to "making warnings either off or fatal like D", thus denying the use case where you want the compiler to report a code situation which is not necessarily "fairly likely" to be a bug, but is still relevant enough to report to the coder, for whatever reason.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Sun, 27 Jul 2008 17:56:01 +0400, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:

> Walter Bright wrote:
>> Nick Sabalausky wrote:
>>> I don't suppose there's any chance of DMD getting a warning for variables/arguments that are declared but never accessed? Just today alone there's been two bugs I spent 10-30 minutes going nuts trying to track down that turned out to be variables I had intended to use but forgot to.
>>  The problem with unused variable warnings is they are annoying when you're developing code in an iterative manner. They get in the way when you're commenting out sections of code to try and isolate a problem. They can be a problem when using "version" and "static if" statements.
>>  So, why not just turn off the warnings?
>>  The problem with warnings is that if there are n warnings, there are essentially n factorial different versions of the language. 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?
>>
>
> You have a distorted notion of warnings. Warnings are not errors (and by corollary are not "optional errors" also). They are simply messages which indicate some "strange" situations in code, which suggest some attention from the developer (now or in the future).
> That's why other compilers have an *option* such as "treat-warnings-as-errors". If they were errors, they wouldn't need that option, cause they would already be treated as errors (cause they would *be* errors...), lol. :(
>
> You (Walter) and other people, may be inclined to disagree, especially if you are heavily biased torwards C++, where warnings, like you said, have been used for *things that should have been errors*, and have created this whole messed up and confused situations, and scenarios where people think C++ code should compile without errors, etc., etc.. But that is just a scenario arising from C++ fucked-up-ness.
>
> If you (and others) still don't agree, which you probably won't, then let's not argue semantics, and just call this notion of warnings that I defined before as "cautions".
> _ With this in mind, what's wrong with the compiler generating messages (and just messages, not errors) for certain suspicious code situations, such as unused variables? Just that, what do you say? _
>
>

Now I agree with Walter on that matter. Compiler's job is to compile an executable. As a gentoo user when I compile something (and I do it alot :p ) I expect two messages: "build finished" *or* "build failed for the following reason: ...". All those warning are *not for me*, they are for developers and needed during development time only. Imagine you are updating a web-browser or some other application and get all those "comparison between signed and unsigned types" messages. Do you want to read them?

OTOH, I want for my code to be constantly analyzed for suspicious situation but _only during development time_. That's why I use IDE. And my IDE should help me as I type: syntax highlighting, code autocomplete, refactoring *and* warnings. It's almost free for IDE to analyze my code for possible errors. But compiler's job is to compile *or* reject the code, and it should do it as fast as possible without spending time for looking into suspicious situations.

Compiler and IDE tasks do often overlap, of course, but it doesn't mean that they should be merged into single solution.

Just my $0.02...