Derek Parnell wrote:

> On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
> , J Anderson <REMOVEanderson@badmama.com.au> wrote:
> 
>> J C Calvarese wrote:
>>
>>> J Anderson wrote:
>>>
>>> I think it'd be impossible to grep, but at least the compiler error messages should point to the code that needs correcting. I'm not sure if it needs changing, but if something this fundamental is going to be changed, now is our opportunity to make the change. Pretty soon, the door will close on that chance.
>>>
>>> D 1.0 hasn't arrived yet, and I don't think we'd be able to make a change here once it does arrive.
>>
>>
>>
>> With my other hat:
>>
>> It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.
>>
> 
> Doesn't an error imply that D cannot continue compiling, whereas a warning means that D can continue but the results may not be what the coder expects.
> 
> A *potential* loss of data due to implicit cast conversions would therefore only warrant a warning at best, as D can continue compiling.
> 

Walter is philosophically against warnings and I think he's right. The idea is if it's alarming enough to warn about, compilation should stop and it should be fixed.


http://www.digitalmars.com/d/overview.html

Under "Who D is For":
People who compile with maximum warning levels turned on and who instruct the compiler to treat warnings as errors.

Under "No Warnings":
D compilers will not generate warnings for questionable code. Code will either be acceptable to the compiler or it will not be. This will eliminate any debate about which warnings are valid errors and which are not, and any debate about what to do with them. The need for compiler warnings is symptomatic of poor language design.

-- 
Justin
http://jcc_7.tripod.com/d/

Derek Parnell wrote:

> On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
> , J Anderson <REMOVEanderson@badmama.com.au> wrote:
>
>> J C Calvarese wrote:
>>
>>> J Anderson wrote:
>>>
>>> I think it'd be impossible to grep, but at least the compiler error messages should point to the code that needs correcting. I'm not sure if it needs changing, but if something this fundamental is going to be changed, now is our opportunity to make the change. Pretty soon, the door will close on that chance.
>>>
>>> D 1.0 hasn't arrived yet, and I don't think we'd be able to make a change here once it does arrive.
>>
>>
>>
>> With my other hat:
>>
>> It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.
>>
>
> Doesn't an error imply that D cannot continue compiling, whereas a warning means that D can continue but the results may not be what the coder expects.

I don't even know if D has any warning messages. Walter hates them (as do I).

>
> A *potential* loss of data due to implicit cast conversions would therefore only warrant a warning at best, as D can continue compiling.


I think it should be an *error* because you can always cast your way out of it.  Casting is like telling the compiler, I know what I'm doing.  The reason I have treat errors as warnings in C++ is that every warning I've come across I've been able to deal with.

IMHO If you have warnings you asking for trouble because people just ignore them.  I've seen peoples programs with hundreds of warnings because people can't be bothered fixing them.  If you say, well I'm not lazy, then making warnings into error messages won't make life harder anyway.  When I bug arrives it is normally because of one of the warnings.  Warnings are bad because they don't force the people to use them.

Since all warnings can be explicitly ignored they should be errors not warnings.

So:
Warnings -> Bad
The warning messages from C++ made into errors in D -> good.

If you argue that warnings are different then errors, then half the D's error messages should become warnings (and then it wouldn't be strongly typed).  There is little no reason why there should be warnings at all, just more errors to help the programmer out.

-- 
-Anderson: http://badmama.com.au/~anderson/

J C Calvarese wrote:

> If Walter doesn't see these implicit casts as a problem, it's possible that a clever D programmer can create a program to check that the variables aren't being implicitly cast in the ways that the OP was concerned about. It sounds like a very ambitious task to me, but I suppose it's possible.


It's passing the buck. I mean, it would be much easier (for just about everyone) to have it in the main program.  Having a separate checker program is just as bad as warnings. 

You can get really good checker programmers that pick up allot of might-be-errors that could never be real errors, but for trivial things like this, it should be an error in the compiler.

> Another check that could be helpful: ensuring that every swtich has a default case (no one likes pesky runtime errors) BEFORE compilation. If the cases are susposed to be specified, it could be "default: assert(0);". If unspecified cases are permitted, it could be default: break;". Walter seems to be unwavering on this controversial issue, but I think this would be an easier thing to check for.
>
> Just thinking outloud...


Check everything I say.  I've met that many programmers who leave warning messages in C++ (because they can't be bothered working out how to fix them) and found that their problem was exactly as the warning message stated.

I would like it if D
- forced variable initialization,
- made sure all variables where used,

It just makes it so much easier if the compiler does this kinda redundant thinking for me and I can focus on the higher level stuff.

-- 
-Anderson: http://badmama.com.au/~anderson/


-- 
-Anderson: http://badmama.com.au/~anderson/

On Tue, 24 Feb 2004 19:36:16 -0600 (02/25/04 12:36:16)
, J C Calvarese <jcc7@cox.net> wrote:

> Derek Parnell wrote:
>
>> On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
>> , J Anderson <REMOVEanderson@badmama.com.au> wrote:
>>
>>> J C Calvarese wrote:
>>>
>>>> J Anderson wrote:
>>>>
>>>> I think it'd be impossible to grep, but at least the compiler error messages should point to the code that needs correcting. I'm not sure if it needs changing, but if something this fundamental is going to be changed, now is our opportunity to make the change. Pretty soon, the door will close on that chance.
>>>>
>>>> D 1.0 hasn't arrived yet, and I don't think we'd be able to make a change here once it does arrive.
>>>
>>>
>>>
>>> With my other hat:
>>>
>>> It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.
>>>
>>
>> Doesn't an error imply that D cannot continue compiling, whereas a warning means that D can continue but the results may not be what the coder expects.
>>
>> A *potential* loss of data due to implicit cast conversions would therefore only warrant a warning at best, as D can continue compiling.
>>
>
> Walter is philosophically against warnings and I think he's right. The idea is if it's alarming enough to warn about, compilation should stop and it should be fixed.

Okay, thanks for that. I guess my point was regardless of what you call these messages, warnings or errors, it is often useful to continue compiling in some cases so that as many messages as possible are produced per compilation run. This allows coders to correct many problems before resubmitting to compilation.

I too don't really care if a message is classified as an error or warning, it still needs to be fixed up. What I do care about is being effecient in my work practices so I can keep costs down. And any reductions in the analyse-edit-compile-test loop are welcome.

-- 
Derek

J Anderson wrote:
> 
> It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.

Agreed.  I always compile with warnings set at max level and only ignore those produced by third-party libraries (because I have to).  Except for some silly ones that have no context in D, all C++ warnings should be treated as errors in D.


Sean

Sean Kelly wrote:

> J Anderson wrote:
>
>>
>> It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.
>
>
> Agreed.  I always compile with warnings set at max level and only ignore those produced by third-party libraries (because I have to).  Except for some silly ones that have no context in D, all C++ warnings should be treated as errors in D.
>
>
> Sean
>
In C++ I put push-pop the warning level for every file (it's in my cpp template so it's not effort).  That way third party are no problem.

-- 
-Anderson: http://badmama.com.au/~anderson/

Thats interesting, I take a different approach. Write 5 - 10 lines, compile, fix the errors which is usually minimal.  PCH and faster machines make this possible ( unless your using GCC :/ ) to be really effecient, and I almost never have to debug.

C

On Wed, 25 Feb 2004 13:02:11 +1100, Derek Parnell <Derek.Parnell@Psyc.ward> wrote:

> On Tue, 24 Feb 2004 19:36:16 -0600 (02/25/04 12:36:16)
> , J C Calvarese <jcc7@cox.net> wrote:
>
>> Derek Parnell wrote:
>>
>>> On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
>>> , J Anderson <REMOVEanderson@badmama.com.au> wrote:
>>>
>>>> J C Calvarese wrote:
>>>>
>>>>> J Anderson wrote:
>>>>>
>>>>> I think it'd be impossible to grep, but at least the compiler error messages should point to the code that needs correcting. I'm not sure if it needs changing, but if something this fundamental is going to be changed, now is our opportunity to make the change. Pretty soon, the door will close on that chance.
>>>>>
>>>>> D 1.0 hasn't arrived yet, and I don't think we'd be able to make a change here once it does arrive.
>>>>
>>>>
>>>>
>>>> With my other hat:
>>>>
>>>> It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.
>>>>
>>>
>>> Doesn't an error imply that D cannot continue compiling, whereas a warning means that D can continue but the results may not be what the coder expects.
>>>
>>> A *potential* loss of data due to implicit cast conversions would therefore only warrant a warning at best, as D can continue compiling.
>>>
>>
>> Walter is philosophically against warnings and I think he's right. The idea is if it's alarming enough to warn about, compilation should stop and it should be fixed.
>
> Okay, thanks for that. I guess my point was regardless of what you call these messages, warnings or errors, it is often useful to continue compiling in some cases so that as many messages as possible are produced per compilation run. This allows coders to correct many problems before resubmitting to compilation.
>
> I too don't really care if a message is classified as an error or warning, it still needs to be fixed up. What I do care about is being effecient in my work practices so I can keep costs down. And any reductions in the analyse-edit-compile-test loop are welcome.
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Sark7 wrote:
> I think that implicit casting from greater space to lesser space should be not allowed, because imho it isn't logically correct.
> 
> for example:
> 
> unit -> int  // ok
> int  -> uin  // error
> 
> float -> double // ok
> double -> float // error
> 
> int   -> float // ok
> float -> int   // error
> 
> -- 
> Sark7

Your post and some of the replied got me thinking...

Okay, I know it's "Garbage In, Garbage Out," but it seems to me there's multiple reasons why the code below might raise a compile-time error.

First of all, I would expect an error when I initialize the uint j to a negative number. Is the compiler being too forgiving here? I guess there's a fine between a harrassing compiler and a too lenient compilation process.

I'm also disturbed the implicit casting from int to uint (and uint to int, too), but I'm afraid it'll be painful if the compiler starts disallowing all of this activity. I haven't really made up my mind yet.



import std.c.stdio;

void printInt(int i)
{
   printf("%d\n", i);
}

void printUint(uint u)
{
   printf("%d\n", u);
}


void main()
{
   int i = -2000000000;
   uint j = -1000000000;


   printInt(i);
   printInt(j);
	
   printUint(i);
   printUint(j);	
}

/+

Output:
-2000000000 // expected
-1000000000 // somewhat expected
2294967296  // nonsense
3294967296  // nonsense

+/


-- 
Justin
http://jcc_7.tripod.com/d/

C wrote:

> Thats interesting, I take a different approach. Write 5 - 10 lines, compile, fix the errors which is usually minimal.  PCH and faster machines make this possible ( unless your using GCC :/ ) to be really effecient, and I almost never have to debug.
>
> C
>
When you get a large program, it can take even hours to compile.  Often the machines are setup make a recompile overnight and you hand the error messages over to the appropriate people the next day.  Adding unit testing to that and it can get really big.

Of course you can reduce compile time by chopping it up into libraries but you still can have long compile times.

I find programming a heap and then compiling is much more efficient then being a trigger happy coder.  Even the pressing of F5 and looking to see if there is error messages is a slow down.  It's also faster to fix 10 of the same types of errors in one go then one error 10 times.  Fast coding is what it is about otherwise you get less done.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:
> J C Calvarese wrote:
> 
>> If Walter doesn't see these implicit casts as a problem, it's possible that a clever D programmer can create a program to check that the variables aren't being implicitly cast in the ways that the OP was concerned about. It sounds like a very ambitious task to me, but I suppose it's possible.
> 
> It's passing the buck. I mean, it would be much easier (for just about 

I'm not passing the buck for Walter. I'm trying to show that maybe a compromise is possible. Fine, you don't consider this an option. It was just a suggestion. I'm sorry if you saw it as a cop-out. That's not how I intended it.

I'm not going to track down a particular message, but I suspect this has been brought up before. He seems to have already made up his mind of this issue. If Walter doesn't think this is the thing to do, he won't do it. But we can still try to change his mind by ganging up on him...

> everyone) to have it in the main program.  Having a separate checker program is just as bad as warnings.
> You can get really good checker programmers that pick up allot of might-be-errors that could never be real errors, but for trivial things like this, it should be an error in the compiler.
> 
[...]
>>
>> Just thinking outloud...
> 
> Check everything I say.  I've met that many programmers who leave warning messages in C++ (because they can't be bothered working out how to fix them) and found that their problem was exactly as the warning message stated.
> 
> I would like it if D
> - forced variable initialization,
Please, no.

Let the compiler do this. int=0. double=nan. char="". object=null. That's good enough for me. I know others disagree. If you disagree, the hypothetical independent checking program can help you out.

> - made sure all variables where used,
Please, no.

Often when I'm debugging (or writing a new program), I'm don't intend to use all the variables every time a compile. I don't need the compiler breathing down my neck about it about "proper coding processes" when I'm trying chase down a bug.

> It just makes it so much easier if the compiler does this kinda redundant thinking for me and I can focus on the higher level stuff.

-- 
Justin
http://jcc_7.tripod.com/d/