Regarding compiler switches

[div0]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Sabalausky wrote:

> You're missing my point. To briefly reiterate: I proposed adding an optional 
> switch to let people treat warnings as errors, and you were adamant that 
> shouldn't get added ("NO NO NO NO NO!"), which would indicate you consider 
> it better to force all warnings to be errors than to allow users to 
> optionally make them non-fatal.
> I'm well aware you want a lack of warnings, but *that wasn't the question*. 
> The question was, *given a situation where there ARE warnings*, particularly 
> current real-world C/C++ since that's the example you used, why do you 
> consider it *better* to not allow anyone to compile with warnings as 
> non-fatal (as opposed to allowing people to have their warnings non-fatal if 
> they want to)? Whether or not warnings should exist in the first place is 
> *not part of the question*.

Ok fair dos, I agree with you that warnings should [not exist at all] be
warnings not errors.

But if you like warnings so much please provide a concrete example of a
compilation run that's given you a useful warning that you've then used
to correct a problem with your code.

For me doing C++ with visual studio, the only time that has happened is:

====
   if(true);
====
{WARNING}

main.cpp(47) : warning C4390: ';' : empty controlled statement found;
is 	this the intent?
====

Do the same with DMD:

====
   if(true);
====
{ERROR}

test.d(2): use '{ }' for an empty statement, not a ';'
====

For every situation I believe that there is a simple and unambiguous
right/wrong choice and D's design pretty much does away with all those
pointless warnings and it makes stupid things errors.

As another for instance, WB decided that shadowing variable names are
wrong and has disallowed them.

Now I personally disagree with that choice as I've never been bitten by
a bug that has caused and I also tend to write code which does quite a
bit of shadowing declarations.

However making the choice to make it an error rather than a warning is
definitely correct as far as I'm concerned. Errors get corrected
(because you have to) and warnings get ignored.

I've spent 100s of hours over the past 8 years where I work fixing
shitty code written by dribbling morons who couldn't be bothered to fix
the warnings that their code generated and who quite frankly should
never have been employed in the first place.

Given the fact that you are a NG posting, D loving weirdo your code is
probably very good and well documented and probably it compiles with out
generating any warnings at all, but you and the code you write is rare &
odd.

Most of the code that's done out there by 'normal programmers' whose
only concern is getting paid at the end of the month basically sucks, so
making things errors, which they have to fix rather than warnings is the
way to go, from my pragmatic working coders point of view.

Though I suppose you can throw the lint tool argument right back at me
and say that people that employee morons should run a lint tool.

>>> Besides, I've been starting to wonder if the *real* problem isn't that
>>> warning settings always get propogated to libraries (instead of being
>>> settable on a package-by-package basis. For instance, why shouldn't a
>>> programmer be able to tell the compiler "I want these warning settings 
>>> for
>>> this app I'm compiling, but to hell with any potential warnings in xx and 
>>> yy
>>> libraries because that ain't my damn code so don't bug me with it right
>>> now!"?). I'd think that would fix all those problems with warnings that
>>> you've described, at least for the most part. Of course, that probably 
>>> can't
>>> be fixed in C++ (but then, what *can* be fixed in C++? ;) ), but D 
>>> actually
>>> has a module system which should make it possible, at least in theory.

>> That's a really good idea. Any chance of a patch?

> I'd love to give it a shot, unfortunately I already have a lot on my plate 
> right now. Maybe I'll get to it sometime though :/.

lol. I know what you mean, my todo list is growing at an exponential
rate. By the time I die, I'm going to need at least 4 more lifetimes to
catch up on it.

> But one problem is, Walter has already indicated that he's not particularly 
> interested in adding new warning-related compiler switches, so unless that 
> changes, there are a lot of other things I can work on that don't have a 
> high likelyhood of being ignored just like my #2567 "-ww" "warnings as 
> warnings" patch.

Always a problem. Maybe a patch which does your new idea would have a
better chance though, as that way people would have the best of both worlds.

> 
 > First of all, just to be clear, I should point out that I really meant
> "parse+semantics and mixin expansion, etc", not just "parse" because all of 
> that stuff, everything before optimization and codegen, will need to be done 
> for a good lint tool.

True, but that is all front end stuff and the front end is open source
so doing a lint tool would be easy for anybody who feels that strongly
about it.

> 
> Second thing I want to point out, to be clear, is that I would want to set 
> up the lint tool to run on every build. The reason for that should be fairly 
> clear, as it's the same reason people prefer compile-time errors over 
> run-time errors: I want those messages because they might indicate bugs or a 
> potential for bugs, and if there's potential bugs, I want it be brought to 
> my attention as early as possible, such as, on the first build after they 
> were introduced into the code in the first place. Doing otherwise would 
> defeat much of the potential usefulness of a lint tool.

> Ok, so with that out of the way, to answer your question of "what's wrong 
> with rerunning the whole parse process?":
> 
> Well, first of all, why? It's the same damn thing that needs to get done, so 
> what the hell's the point?

Well one point is, CPU time is very cheap, human time is very expensive.

> Secondly, templates and CTFE slow down the whole process. And being that 
> those are two of D's killer features, their effect on compilation time is 
> just going to get felt more and more.

really? what's the maximum time you've waited for dmd to finish
compiling? I've never seen it take more than a 1 second; however my D
apps aren't big or complicated so maybe I've not run into your problems.

> And with that in mind, thirdly, every little bit of extra speed when 
> building aids the whole modify/build/test cycle. It doesn't take the 
> absurdly out-of-control C/C++-level build times to start hindering that 
> cycle. Even shaving a 15 second build down to 10 seconds (and I would even 
> argue the same point with lesser numbers than that) is enough to notably 
> improve productivity.

Sorry but I think that's rubbish. In my experience 99% of developer time
is spent either debugging problems, sat at a desk scribbling diagrams
and solving problems or being on the phone to the client.

If saving a few second during a compilation really improves your
productivity you must be a really crappy programmer, which can't be
true; you are obviously not that stupid.

> And finally, if a lint tool is built into the compiler, and you really want 
> compile and lint treated separately, and you don't care about duplicated 
> processing, then all you have to do is change "dmd -w" to "dmd -w -c"/"dmd". 
> So there you go: Eating cake and still having it.

Good point, but then you need to persuade Walter to support all that
lint functionality which would be redundant if the language was
sufficiently well specified. I'd rather see the effort put into closing
off the corner cases, maybes and undefined functionally.

> I'll grant that rerunning the whole parse would be perfectly fine for an 
> initial version of a lint tool, but as a permanent design it's just simply 
> idiotic wasteful programming.

? I really don't understand your reluctance to burn cpu cycles.
To me you seem to be suffering from a bad case of premature optimisation.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFK9OAVT9LetA9XoXwRAs26AJ9Ij4R4Uq2ID9Q7zyIsjdri4LjVqgCgwcWJ
OyKORD8JdJGzY5CtPWjyjdY=
=1SK1
-----END PGP SIGNATURE-----