www.digitalmars.com         C & C++   DMDScript  

D - Implicit casting

reply Sark7 <sark7 mail333.com> writes:
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
Feb 23 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I couldn't agree more


"Sark7" <sark7 mail333.com> wrote in message
news:opr3ux0xcvut8jae news.digitalmars.com...
 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

Feb 23 2004
parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Tue, 24 Feb 2004 15:58:24 +1100 (02/24/04 15:58:24)
, Matthew <matthew.hat stlsoft.dot.org> wrote:

 I couldn't agree more


 "Sark7" <sark7 mail333.com> wrote in message
 news:opr3ux0xcvut8jae news.digitalmars.com...
 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


At the very least, a warning message would be nice. The general principle being that if a implicit cast can possibly cause loss of information at run-time, then the coder should be made aware of it. Excuse my ignorance, but what about the case where two floats are multiplied and the result assigned to a third float. Does D cause the first two floats to be promoted to a double such that the calculated product (temporary result) is a double prior to being assigned to storage? float a,b, c; a = 12.3456789012; b = 23.4567890123; c = a * b; -- Derek -- Derek
Feb 23 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Derek Parnell" <Derek.Parnell Psyc.ward> wrote in message
news:opr3u0mvnhdeu3pf news.digitalmars.com...
 On Tue, 24 Feb 2004 15:58:24 +1100 (02/24/04 15:58:24)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:

 I couldn't agree more


 "Sark7" <sark7 mail333.com> wrote in message
 news:opr3ux0xcvut8jae news.digitalmars.com...
 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


At the very least, a warning message would be nice. The general principle being that if a implicit cast can possibly cause loss of information at run-time, then the coder should be made aware of it. Excuse my ignorance, but what about the case where two floats are multiplied and the result assigned to a third float. Does D cause the first two floats to be promoted to a double such that the calculated product (temporary result) is a double prior to being assigned to storage? float a,b, c; a = 12.3456789012; b = 23.4567890123; c = a * b;

I would expect that to be the case, but I don't know
Feb 23 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

multiplied and the result assigned to a third float. Does D cause the
first two floats to be promoted to a double such that the calculated
product (temporary result) is a double prior to being assigned to storage?

   float a,b, c;

    a = 12.3456789012;
    b = 23.4567890123;
    c = a * b;
    

I would expect that to be the case, but I don't know

is a compile time one (like would be possible with the example given). -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
prev sibling next sibling parent reply Juan C <Juan_member pathlink.com> writes:
In article <opr3ux0xcvut8jae news.digitalmars.com>, Sark7 says...
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

I thought that was already true.
Feb 23 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
Juan C wrote:

 I thought that was already true.

But why do you think that this is true? May I cite a recent posting of yours?: | [...] the language shouldn't prevent the user from making errors. I cannot find anything illegal in casting into lesser space in that case, that the actual source value fits into the range of the target type. So long.
Feb 24 2004
prev sibling next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Sark7 wrote:

[...]
 imho it isn't logically correct.

That depends on the logic you want to use. Why should it be "logically incorrect" to implicitly cast from a type with fine resolution, small range of values and much space to a type with coarser resolution, broader range of values and less space? [...]
 unit -> int  // ok
 int  -> uin  // error

If you mean `uint' and `int' here, then why should it be "logically correct" to implicitly cast an actual value of `int.max + 1', which can be hold by an `uint', to an `int'? So long.
Feb 24 2004
prev sibling next sibling parent Steve Adams <adamss ascinet.com> writes:
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

I agree.
Feb 24 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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

But uint's can be greater then int's. I don't think either should be allowed without a cast.
 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error

I think float/double to int should also have a forced cast. Most of the time you are using floating point for calculations that need the fraction part and accidental conversion to int can be a real problem. However, I think these things are to late to change now, it's kinda engrained in D now and would cause to many changes in stuff that is already written. -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
parent reply larry cowan <larry_member pathlink.com> writes:
An important point is that implicit casting where it's not guaranteed to be safe
is DANGEROUS.

And especially in large systems of code and in later maintenance changes.

THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
TIME.

It should be reconsidered whether or not it breaks Phobos or other projects
developed or in-work.  Explicit casting need not have such limitations - it can
be searched for and any problems can be dealt with.  The correction of the
limited amount of long-term current code can be fixed by explicit casting when
the compiler starts rejecting it.

-larry

In article <c1g43k$11he$1 digitaldaemon.com>, J Anderson says...
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

But uint's can be greater then int's. I don't think either should be allowed without a cast.
 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error

I think float/double to int should also have a forced cast. Most of the time you are using floating point for calculations that need the fraction part and accidental conversion to int can be a real problem. However, I think these things are to late to change now, it's kinda engrained in D now and would cause to many changes in stuff that is already written. -- -Anderson: http://badmama.com.au/~anderson/

Feb 24 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Just playing devils advocate:

larry cowan wrote:

An important point is that implicit casting where it's not guaranteed to be safe
is DANGEROUS.

And especially in large systems of code and in later maintenance changes.

THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
TIME.
  

best to stick with what we have at the moment.
It should be reconsidered whether or not it breaks Phobos or other projects
developed or in-work.  Explicit casting need not have such limitations - it can
be searched for and any problems can be dealt with.  The correction of the
limited amount of long-term current code can be fixed by explicit casting when
the compiler starts rejecting it.
  

by hand. However its merits should be considered of course.
-larry
  

-Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
next sibling parent larry cowaqn <larry_member pathlink.com> writes:
In article <c1g8fi$1978$1 digitaldaemon.com>, J Anderson says...
Just playing devils advocate:

larry cowan wrote:

An important point is that implicit casting where it's not guaranteed to be safe
is DANGEROUS.

And especially in large systems of code and in later maintenance changes.

THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
TIME.
  

best to stick with what we have at the moment.

I understand, but like I mentioned, it's easy to include in the spec now, valuable, and need not be included in the 1.0 compiler which will have errors if only in things we haven't found yet. It should be considered on its merits.
It should be reconsidered whether or not it breaks Phobos or other projects
developed or in-work.  Explicit casting need not have such limitations - it can
be searched for and any problems can be dealt with.  The correction of the
limited amount of long-term current code can be fixed by explicit casting when
the compiler starts rejecting it.
  

by hand. However its merits should be considered of course.

As far as grepping for explicit casts, it needs only anything with reasonable re-like acceptance, and could be either for 'cast' or 'cast\s*\(float\s*\**\)' or some such. If grep wouldn't find what you wanted, a simple perl program could scan the code.
-larry
  

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

Feb 24 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
J Anderson wrote:
 Just playing devils advocate:
 
 larry cowan wrote:
 
 An important point is that implicit casting where it's not guaranteed 
 to be safe
 is DANGEROUS.

 And especially in large systems of code and in later maintenance changes.


 It's difficult to grep and therefore in most cases would have to be done 
 by hand.  However its merits should be considered of course.

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. -- Justin http://jcc_7.tripod.com/d/
Feb 24 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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. -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
next sibling parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
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. -- Derek -- Derek
Feb 24 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Feb 24 2004
parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
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
Feb 24 2004
parent reply C <dont respond.com> writes:
Thats interesting, I take a different approach. Write 5 - 10 lines, =

compile, fix the errors which is usually minimal.  PCH and faster machin=
es =

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 erro=





 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) a=




 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 th=



 coder expects.

 A *potential* loss of data due to implicit cast conversions would =



 therefore only warrant a warning at best, as D can continue compilin=




Walter is philosophically against warnings and I think he's right. Th=


 idea is if it's alarming enough to warn about, compilation should sto=


 and it should be fixed.

Okay, thanks for that. I guess my point was regardless of what you cal=

 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/
Feb 24 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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

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/
Feb 24 2004
parent reply larry cowan <larry_member pathlink.com> writes:
In article <c1h5j8$2t80$1 digitaldaemon.com>, J Anderson says...
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

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/

Don't you have a dev platform that you can at least compile individual modules locally before putting them in to a huge build you might break? If its that big there must be a lot of people with the potential for breaking it with a dumb error once a month each. While I would like the compiler to go as far as it can do so effectively, spitting out 10 identical errors is not very useful - there will be a quitting point somewhere that may not be the last occurrence. Searching for more instances of the same error or context when you see one errmsg (or at least if you see more than one) may not be a lot of fun, but it usually can be done. If you don't code a horrendous amount before checking (locally) you probably know when you see the first occurrence whether there are potentially more of the same - and you won't continue coding additional ones. Getting lots done is great, but getting lots done right is more to the point. Anyway, you don't program systems, you program modules - which is what unit testing is all about. If every module works right, getting the system to work right is much easier.
Feb 24 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
larry cowan wrote:

While I would like the compiler to go as far as it can do so effectively,
spitting out 10 identical errors is not very useful - there will be a quitting
point somewhere that may not be the last occurrence.  Searching for more
  

all occuraces and then to the rest, but my point is, my mind at least is in error termination mode when I'm doing this. I used to be a trigger happy programmer but that that was only at the beginning when learning the language.
instances of the same error or context when you see one errmsg (or at least if
you see more than one) may not be a lot of fun, but it usually can be done.  If
you don't code a horrendous amount before checking (locally) you probably know
when you see the first occurrence whether there are potentially more of the same
- and you won't continue coding additional ones.
  

How many lines of code (on average) do you know you can program without error? IMHO This is how many you should write before checking. I don't code up the entire program just each algorithm, get it right and then test it in once go. Otherwise I need to generate a lot more debugging (which gets scrapped latter on). Also I always try to complete the algorithm before leaving so I know what's new. I think as I get better, I'll need to check even less and to be able to program more with less checking intervals. It's like spell checking, when typing you don't spell check till after you've finished (Yes. I'm still guilty of checking every paragraph rather then the entire document at the end). If you stop at every spelling mistake, you can't go as fast. Then you re-read it and make sure the draft you've typed is correct. Anyhow, I guess I'm a top-down programmer and your a bottom up. There are pros and cons of both, so I guess there's no right answer. -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
J Anderson wrote:
 ...
 and to be able to program more with less checking intervals.  It's
 like spell checking, when typing you don't spell check till after
 you've finished (Yes. I'm still guilty of checking every paragraph
 rather then the entire document at the end). If you stop at every
 spelling mistake, you can't go as fast.  Then you re-read it and
 make sure the draft you've typed is correct.
 ...

Humbly (sp?), I can say I don't make spelling mistakes in Spanish. But every time I doubt about a word, I check how I wrote it. Now, that happens in about one or two words each page. If that's too when programming, then when someone really masters programming, s/he would write hundreds of lines of code and just stops to check one line here or there? Eventually could go as far as doing an entire module just compiling at the end? I'd like to know if there's someone who can really do that. ----------------------- Carlos Santander Bernal
Feb 27 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Carlos Santander B. wrote:

J Anderson wrote:
  

...
and to be able to program more with less checking intervals.  It's
like spell checking, when typing you don't spell check till after
you've finished (Yes. I'm still guilty of checking every paragraph
rather then the entire document at the end). If you stop at every
spelling mistake, you can't go as fast.  Then you re-read it and
make sure the draft you've typed is correct.
...
    

Humbly (sp?), I can say I don't make spelling mistakes in Spanish. But every time I doubt about a word, I check how I wrote it. Now, that happens in about one or two words each page. If that's too when programming, then when someone really masters programming, s/he would write hundreds of lines of code and just stops to check one line here or there?

then I just need to fill in the blanks. Things like getters/setters are easily filled in without any checking. The real meat is the difficult (which is a relative term) algorithms. Often I just write out what I'm going to do in comment form then fill in all the blanks, this includes any sub-routines. Once that's done then I compile (and might-run if there's no mistake). These algorithms are usually a couple of 100 lines. Of course the algorithms generally aren't fully semanticly correct, but because the entire algorithm is there I can see the bigger picture in my head better. My period between running and testing the algorithms can be much longer then the syntactical correction, particularly because many of my algorithm require a couple of minutes (or hours) to run. But that's just my style, you might find something else works for you.
Eventually could go as
far as doing an entire module just compiling at the end? I'd like to know if
there's someone who can really do that.

module and get that working before checking. I would only do as much as I can comprehend and only in one sitting. Sometimes that means compiling after a few lines but more generally a few hundred. I generally try to make sure everything is working (that I was working) before I leave a sit-in because I know if I go away I'll forget something.
-----------------------
Carlos Santander Bernal
  

-Anderson: http://badmama.com.au/~anderson/
Feb 27 2004
prev sibling parent Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Tue, 24 Feb 2004 21:36:45 -0800 (02/25/04 16:36:45)
, C <dont respond.com> 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

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

[snip]
 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.


I agree. That too is how I tend to work nowadays, based on the theory that any new errors are most likely to be in the lines just add or changed. But the principle about reducing the cost of development still applies. And there are still those times when a one line change can now cause a ripple of errors in code that was written months ago ;-) -- Derek
Feb 24 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Feb 24 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
J Anderson 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.

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. 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... -- Justin http://jcc_7.tripod.com/d/
Feb 24 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Feb 24 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
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,

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,

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/
Feb 24 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
J C Calvarese wrote:

 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...

Sorry, I didn't mean you, I was talking about D, and Walter. D is passing the buck to another program if it doesn't do these changes because *it can be done in another program by others*. Passing the buck can be a good idea in some situations. -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
parent J C Calvarese <jcc7 cox.net> writes:
J Anderson wrote:
[...]
 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...

Sorry, I didn't mean you, I was talking about D, and Walter. D is passing the buck to another program if it doesn't do these changes because *it can be done in another program by others*. Passing the buck can be a good idea in some situations.

Oh, OK. I misunderstood. I am concerned about this casting issue. I'm not looking forward to the idea of putting a bunch of new casts in my old code, but the implicit casts seems like they could cause some serious problems. (The way that I write code, I've probably already been adversely affected. :) .) -- Justin http://jcc_7.tripod.com/d/
Feb 24 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
 - 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.

variables initalizion points). If you have loose variables around in debugging code, it can cause more unexpected bugs. -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
J Anderson wrote:
 - made sure all variables where used,

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.

variables initalizion points). If you have loose variables around in debugging code, it can cause more unexpected bugs.

I don't understand. If they're unused, aren't they just "inert"? -- Justin http://jcc_7.tripod.com/d/
Feb 24 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
J C Calvarese wrote:

 J Anderson wrote:

 - 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.

variables initalizion points). If you have loose variables around in debugging code, it can cause more unexpected bugs.

I don't understand. If they're unused, aren't they just "inert"?

void func() { int t; for (t ...) //error t is used without initialization } ie void func() { int t; //error t is not used } in C++ you could do one of either to shut the compiler up... void func() { //int t; } or void func() { int t; t; } ie void func(int t) //error t not used. { } in C++ you could do one of either to shut the compiler up... void func(int) { } or void func(int t ) { t; } Not much effort, for the compiler to help catch you out. -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
parent reply larry cowan <larry_member pathlink.com> writes:
But then is it going to complain about struct members not used (by this module,
but by 3 other modules which see the struct) and class methods not used - that
could really get painful...

Or should it be smart enough to know that an extern is being generated or some
instance or reference is being passed to an external function; and then suppress
the message?

Between unwanted pain and uncontrollable leakage it just seems a bad idea.  We
have enough problems with the occassional need to compile all the modules
together to get all the errors to show up - or prevent the linker from losing
something (and I'm not happy with having to dummy instantiate all the types I'm
going to give my template in the template module to get a usable object).

Matthew - I don't envy you when you do your DTL.  So far arbitrary type
templates are chimera unless you code them in the local module or stack them
into your compile (as opposed to link stage).

In article <c1hcen$88h$2 digitaldaemon.com>, J Anderson says...
J C Calvarese wrote:

 J Anderson wrote:

 - 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.

variables initalizion points). If you have loose variables around in debugging code, it can cause more unexpected bugs.

I don't understand. If they're unused, aren't they just "inert"?

void func() { int t; for (t ...) //error t is used without initialization } ie void func() { int t; //error t is not used } in C++ you could do one of either to shut the compiler up... void func() { //int t; } or void func() { int t; t; } ie void func(int t) //error t not used. { } in C++ you could do one of either to shut the compiler up... void func(int) { } or void func(int t ) { t; } Not much effort, for the compiler to help catch you out. -- -Anderson: http://badmama.com.au/~anderson/

Feb 24 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
larry cowan wrote:

But then is it going to complain about struct members not used (by this module,
but by 3 other modules which see the struct) and class methods not used - that
could really get painful...
  

level. Have you ever used full warnings with treat warnings as errors in C++?
Or should it be smart enough to know that an extern is being generated or some
instance or reference is being passed to an external function; and then suppress
the message?
  

is passed to any function it is considered used.
Between unwanted pain and uncontrollable leakage it just seems a bad idea.  We
have enough problems with the occassional need to compile all the modules
together to get all the errors to show up - or prevent the linker from losing
  

basic. If its a standard error message module creators have to fix it so there should be less problems. In my experience 99% of the time the warnings will not show up because the code is correct. Other other 1% you can simply explicitly specify what you meant. Of course there is the cases where stubs are created, but they need to be fixed eventually anyway.
something (and I'm not happy with having to dummy instantiate all the types I'm
going to give my template in the template module to get a usable object).
  

ect...). Particularly since you pass objects by reference, they can be changed in the function called anyway so that a no no.
Matthew - I don't envy you when you do your DTL.  So far arbitrary type
templates are chimera unless you code them in the local module or stack them
into your compile (as opposed to link stage).

  

done in C++ for ages as warnings, I don't see the problem in changing warnings to error messages (C++ even allows you to do this but it's not a default). I'm sure you've got some good points in there somewhere, and I'm just not getting them ;)
In article <c1hcen$88h$2 digitaldaemon.com>, J Anderson says...
  

J C Calvarese wrote:

    

J Anderson wrote:

      

- made sure all variables where used,
            

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.

variables initalizion points). If you have loose variables around in debugging code, it can cause more unexpected bugs.


void func() { int t; for (t ...) //error t is used without initialization } ie void func() { int t; //error t is not used } in C++ you could do one of either to shut the compiler up... void func() { //int t; } or void func() { int t; t; } ie void func(int t) //error t not used. { } in C++ you could do one of either to shut the compiler up... void func(int) { } or void func(int t ) { t; } Not much effort, for the compiler to help catch you out. -- -Anderson: http://badmama.com.au/~anderson/


-- -Anderson: http://badmama.com.au/~anderson/
Feb 25 2004
prev sibling parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
J C Calvarese wrote:
 J Anderson 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.

If Walter doesn't see these implicit casts as a problem, it's possible

Walter wrote:
 I've changed the language so that floating point values are no longer
 implicitly converted to integral types.

... in thread "[Language design] yet another notational error" Walter, does this mean you'll disallow implicit casts to lesser-space in all cases (ie uints/ints etc etc etc)? Please? ;) Cheers, Sigbjørn Lund Olsen
Feb 25 2004
parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Wed, 25 Feb 2004 15:18:05 +0100 (02/26/04 01:18:05)
, Sigbjørn Lund Olsen <sigbjorn lundolsen.net> wrote:

 J C Calvarese wrote:



 If Walter doesn't see these implicit casts as a problem, it's possible

Walter wrote: > I've changed the language so that floating point values are no longer > implicitly converted to integral types. ... in thread "[Language design] yet another notational error" Walter, does this mean you'll disallow implicit casts to lesser-space in all cases (ie uints/ints etc etc etc)?

If implicit casting is not an error and cannot be a despicable warning, would it still be useful as an 'informational' message. In my case, I'd like to know where all cases of D doing this occurs so that I can either change datatypes or make the cast explicit, or even something else. Its not always obvious to the human eye where such implicit casts exist. -- Derek
Feb 25 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Derek Parnell wrote:
[...]
 
 If implicit casting is not an error and cannot be a despicable warning, 
 would it still be useful as an 'informational' message. In my case, I'd 
 like to know where all cases of D doing this occurs so that I can either 
 change datatypes or make the cast explicit, or even something else. Its 
 not always obvious to the human eye where such implicit casts exist.
 

Your description of an "informational" message sounds eerily similar to what I thought a "warning" message was. :) -- Justin http://jcc_7.tripod.com/d/
Feb 25 2004
parent Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Wed, 25 Feb 2004 17:35:16 -0600 (02/26/04 10:35:16)
, J C Calvarese <jcc7 cox.net> wrote:

 Derek Parnell wrote:
 [...]
 If implicit casting is not an error and cannot be a despicable warning, 
 would it still be useful as an 'informational' message. In my case, I'd 
 like to know where all cases of D doing this occurs so that I can 
 either change datatypes or make the cast explicit, or even something 
 else. Its not always obvious to the human eye where such implicit casts 
 exist.

Your description of an "informational" message sounds eerily similar to what I thought a "warning" message was. :)

Yah think ? ;-) -- Derek
Feb 25 2004
prev sibling parent reply Sean Kelly <sean ffwd.cx> writes:
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
Feb 24 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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

template so it's not effort). That way third party are no problem. -- -Anderson: http://badmama.com.au/~anderson/
Feb 24 2004
prev sibling next sibling parent C <dont respond.com> writes:
I completely agree, fixing the pre-existing code should not be too =

dificult , even if its all by hand.

C

On Tue, 24 Feb 2004 19:09:42 +0000 (UTC), larry cowan =

<larry_member pathlink.com> wrote:

 An important point is that implicit casting where it's not guaranteed =

 be safe
 is DANGEROUS.

 And especially in large systems of code and in later maintenance chang=

 THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO=

 THINGS
 BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - =

 A
 SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT =

 COMPILER IN
 TIME.

 It should be reconsidered whether or not it breaks Phobos or other =

 projects
 developed or in-work.  Explicit casting need not have such limitations=

 it can
 be searched for and any problems can be dealt with.  The correction of=

 the
 limited amount of long-term current code can be fixed by explicit =

 casting when
 the compiler starts rejecting it.

 -larry

 In article <c1g43k$11he$1 digitaldaemon.com>, J Anderson says...
 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

But uint's can be greater then int's. I don't think either should be=


 allowed without a cast.

 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error

I think float/double to int should also have a forced cast. Most of =


 time you are using floating point for calculations that need the
 fraction part and accidental conversion to int can be a real problem.=


 However, I think these things are to late to change now, it's kinda
 engrained in D now and would cause to many changes in stuff that is
 already written.

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


-- = Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 24 2004
prev sibling next sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
larry cowan wrote:
 An important point is that implicit casting where it's not guaranteed to be
safe
 is DANGEROUS.
 
 And especially in large systems of code and in later maintenance changes.
 
 THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
 BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
 SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
 TIME.
 
 It should be reconsidered whether or not it breaks Phobos or other projects
 developed or in-work.  Explicit casting need not have such limitations - it can
 be searched for and any problems can be dealt with.  The correction of the
 limited amount of long-term current code can be fixed by explicit casting when
 the compiler starts rejecting it.

I do agree, and while I've not written large amounts of D code yet, but I would think that when writing code for a language/compiler that is unfinished and incomplete, language changes breaking code really ought not be that big a concern. Especially since D is a language that *does* break backwards compatability to its 'ancestors' C/C++ *precisely* because it wants to deal with problems. Do we really wish to deal with problems in D simply because by 0.79 it was 'too late' to fix them? Besides, and not to step on anybody's toes, but I wouldn't say enormous amounts of code has been written for D at this point, relatively speaking. It would certainly be better to fix the problem that implicit casting can be now than for D 2.0. Cheers, Sigbjørn Lund Olsen
Feb 24 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Coulnd't agree more.

But, ouch!, that shouting hurt my eyes. ;/

"larry cowan" <larry_member pathlink.com> wrote in message
news:c1g7hm$17is$1 digitaldaemon.com...
 An important point is that implicit casting where it's not guaranteed to

 is DANGEROUS.

 And especially in large systems of code and in later maintenance changes.

 THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO

 BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
 SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER

 TIME.

 It should be reconsidered whether or not it breaks Phobos or other

 developed or in-work.  Explicit casting need not have such limitations -

 be searched for and any problems can be dealt with.  The correction of the
 limited amount of long-term current code can be fixed by explicit casting

 the compiler starts rejecting it.

 -larry

 In article <c1g43k$11he$1 digitaldaemon.com>, J Anderson says...
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

But uint's can be greater then int's. I don't think either should be allowed without a cast.
 int  -> uin  // error

 float -> double // ok
 double -> float // error

 int   -> float // ok
 float -> int   // error

I think float/double to int should also have a forced cast. Most of the time you are using floating point for calculations that need the fraction part and accidental conversion to int can be a real problem. However, I think these things are to late to change now, it's kinda engrained in D now and would cause to many changes in stuff that is already written. -- -Anderson: http://badmama.com.au/~anderson/


Feb 24 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Feb 24 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
J C Calvarese wrote:

[...]
 Output:
 -2000000000 // expected
 -1000000000 // somewhat expected
 2294967296  // nonsense
 3294967296  // nonsense

Not confirmed. My output: -2000000000 -1000000000 -2000000000 -1000000000 And the output you got is in no means nonsense, because it is the `uint' interpretation of the specified negative `int' values. What you have to do is to check whether the actual value is in the range of the target type, if you do not already know, that it is in this range. But when done checking, why should the language force you, to now declare that you are really, really shure that you want to cast by requiring an explicit cast? int i; uint j; ... if(uint.min <= i && i <= uint.max)j= cast(uint) i; // ? else throw .... So long.
Feb 25 2004
parent J C Calvarese <jcc7 cox.net> writes:
Manfred Nowak wrote:
 J C Calvarese wrote:
 
 [...]
 
Output:
-2000000000 // expected
-1000000000 // somewhat expected
2294967296  // nonsense
3294967296  // nonsense

Not confirmed. My output: -2000000000 -1000000000 -2000000000 -1000000000

Oops. I meant to use this code in my example: void printUint(uint u) { printf("%u\n", u); /* d => u */ } Thanks for straightening me out.
 
 And the output you got is in no means nonsense, because it is the `uint'
 interpretation of the specified negative `int' values.

OK, I exaggerated. My example is admittedly contrived, but the lack of any compiler errors is still unassuring.
 What you have to do is to check whether the actual value is in the range
 of the target type, if you do not already know, that it is in this range.
 
 But when done checking, why should the language force you, to now declare
 that you are really, really shure that you want to cast by requiring an
 explicit cast?
 
   int i;
   uint j;
   ...
   if(uint.min <= i && i <= uint.max)j= cast(uint) i; // ?
     else throw ....
 
 So long.

Not that long ago, I would have argued in favor of all sorts of implicit casting, but now I think that I was way wrong. I'm just not sure how far I should argue to the other extreme. -- Justin http://jcc_7.tripod.com/d/
Feb 25 2004