• bearophile <bearophileHUGS lycos.com> Aug 20 2010
• Jonathan M Davis <jmdavisprog gmail.com> Aug 20 2010
• Walter Bright <newshound2 digitalmars.com> Aug 20 2010
• bearophile <bearophileHUGS lycos.com> Aug 20 2010

bearophile <bearophileHUGS lycos.com> writes:

Jonathan M Davis:

 The compile must be just as accurate when dealing with warnings as when
dealing 
 with errors.


Nope. If your language (like C#) specs say that uninitialized variables are not
allowed, the compiler has to catch them all and report them as errors.
If your language (C, D, etc) allows you to not use a variable the last time you
have initialized it, and then you want to add a warning that finds such
situations, you don't need the compiler to be 100% accurate, even if some of
such situations are not detected then it's perfectly OK.


 The reason is that any good project is not going to have _any_ 
 warnings in it when it's done. And forcing the programmer to do extra,
pointless 
 stuff just to get rid of them is not good. Java and C# make you do that in 
 various places with variable initialization because they do code flow analysis 
 for variable rather than default initialize variables. Because D default 
 initialiazes everething, that sort of code flow analysis becomes unnecessary.


Note that in my last posts I have never asked for uninitialized variables
warnings or errors, so I think you have misread my posts (I have asked for that
months ago).


 Your example for this exact problem involved a default-initialized variable 
 rather than double-assignment, so if you didn't intend to lump default-
 initialized variables in with double-assigned variables, it was a poor example.


That example was not about default-initialized variables nor double-assigned
ones, it was about a variable that is not used after the last time it is
assigned.
(I agree that was not a good example.)


 or have the compiler not complain when it couldn't be 100% certain. If an 
 algorithm could be devised which was 100% certain and the warning were only 
 given in such cases, then it would likely be acceptable.


In the meantime I have seen you have already commented on the bug report and I
agree with with you write there. Thank you. For the In this specific case I
think "zero false positives" is doable :-)

Bye,
bearophile

Jonathan M Davis <jmdavisprog gmail.com> writes:

On Friday, August 20, 2010 15:11:35 bearophile wrote:
 Jonathan M Davis:
 The compile must be just as accurate when dealing with warnings as when
 dealing with errors.


 Nope. If your language (like C#) specs say that uninitialized variables are
 not allowed, the compiler has to catch them all and report them as errors.
 If your language (C, D, etc) allows you to not use a variable the last
 time you have initialized it, and then you want to add a warning that
 finds such situations, you don't need the compiler to be 100% accurate,
 even if some of such situations are not detected then it's perfectly OK.
 


 
 or have the compiler not complain when it couldn't be 100% certain. If an
 algorithm could be devised which was 100% certain and the warning were
 only given in such cases, then it would likely be acceptable.


 In the meantime I have seen you have already commented on the bug report
 and I agree with with you write there. Thank you. For the In this specific
 case I think "zero false positives" is doable :-)


It's fine to have warnings which don't find all the instances of a problem, 
whereas errors _must_ find all of them. However, what isn't fine is having 
warnings give you false positives. The problem with Java or C# and 
initialization is that they're forced to give you false positives because it's 
an error to not initialize a local variable, and they can't let anything
through 
that has _any_ possibility of not having been initialized. So, I'd argue that 
such features are either misfeatures (and the problem should be dealt with 
another way) or that it should be a warning. Ultimately, what should be avoided 
with regards to errors and warnings are

1. Errors where you have to deal with false positives because the compiler
can't 
be 100% certain (D has generally dealt with this by doing stuff like default 
initialization or putting assert(0); at the end of a function rather than doing 
analysis which isn't 100% certain).

2. Warnings which you cannot get rid of or which force you to do something 
unreasonable to get rid of them.

Having extra warnings which warn you about stuff that the compiler knows is
wrong 
but can't detect 100% of the time shouldn't be a problem as long as the 
programmer realizes that the compiler can't detect it all of the time.

- Jonathan M Davis

Walter Bright <newshound2 digitalmars.com> writes:

bearophile wrote:
 If
 your language (C, D, etc) allows you to not use a variable the last time you
 have initialized it, and then you want to add a warning that finds such
 situations, you don't need the compiler to be 100% accurate, even if some of
 such situations are not detected then it's perfectly OK.


Then you're faced with one of two unpleasant consequences:

1. You have to build the logic of what cases you detect into the specification. 
This leads to user confusion about the why's of this and gives a bad impression 
about the arbitrary nature of it.

2. You are faced with errors building with one compiler and no errors on 
another. I.e. your code loses portability.

bearophile <bearophileHUGS lycos.com> writes:

Walter Bright: 
 Then you're faced with one of two unpleasant consequences:


Just a note. If small parts of the type system are with Phobos or user defined
D code that used the static introspection I have explained a bit here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=115833
Then there is no portability problem of the warnings across different
compilers, because they are part of the program (or the std lib) so you move
them around with the code, across different compilers.

Bye,
bearophile