## D - Implicit casting

• Sark7 (11/11) Feb 23 2004 I think that implicit casting from greater space to lesser space should ...
• Matthew (3/14) Feb 23 2004 I couldn't agree more
• Derek Parnell (17/37) Feb 23 2004 At the very least, a warning message would be nice. The general principl...
• Matthew (3/39) Feb 23 2004 I would expect that to be the case, but I don't know
• J Anderson (5/18) Feb 24 2004 That would be a very bad idea performance wise, unless the calculation
• Juan C (2/13) Feb 23 2004 I thought that was already true.
• Manfred Nowak (7/8) Feb 24 2004 But why do you think that this is true? May I cite a recent posting of
• Manfred Nowak (12/15) Feb 24 2004 That depends on the logic you want to use. Why should it be "logically
• Steve Adams (2/18) Feb 24 2004 I agree.
• J Anderson (11/20) Feb 24 2004 But uint's can be greater then int's. I don't think either should be
• larry cowan (14/38) Feb 24 2004 An important point is that implicit casting where it's not guaranteed to...
• J Anderson (8/24) Feb 24 2004 I think this *feature* could be argued both ways, so IMHO I think it is
• larry cowaqn (8/37) Feb 24 2004 I understand, but like I mentioned, it's easy to include in the spec now...
• J C Calvarese (12/24) Feb 24 2004 I think it'd be impossible to grep, but at least the compiler error
• J Anderson (7/15) Feb 24 2004 With my other hat:
• Derek Parnell (11/26) Feb 24 2004 Doesn't an error imply that D cannot continue compiling, whereas a warni...
• J C Calvarese (17/49) Feb 24 2004 Walter is philosophically against warnings and I think he's right. The
• Derek Parnell (13/49) Feb 24 2004 Okay, thanks for that. I guess my point was regardless of what you call
• C (18/67) Feb 24 2004 Thats interesting, I take a different approach. Write 5 - 10 lines, =
• J Anderson (14/19) Feb 24 2004 When you get a large program, it can take even hours to compile. Often
• larry cowan (17/38) Feb 24 2004 Don't you have a dev platform that you can at least compile individual m...
• J Anderson (23/33) Feb 24 2004 You would only look at the first 2 or 3 out of the 10. Search-replace
• Carlos Santander B. (10/18) Feb 27 2004 Humbly (sp?), I can say I don't make spelling mistakes in Spanish. But e...
• J Anderson (23/47) Feb 27 2004 Generally I use something like rational rose (C++) to build the module,
• Derek Parnell (10/21) Feb 24 2004 [snip]
• J Anderson (24/52) Feb 24 2004 I don't even know if D has any warning messages. Walter hates them (as
• J C Calvarese (16/34) Feb 24 2004 If Walter doesn't see these implicit casts as a problem, it's possible
• J Anderson (20/32) Feb 24 2004 It's passing the buck. I mean, it would be much easier (for just about
• J C Calvarese (22/50) Feb 24 2004 I'm not passing the buck for Walter. I'm trying to show that maybe a
• J Anderson (7/27) Feb 24 2004 Sorry, I didn't mean you, I was talking about D, and Walter. D is
• J Anderson (5/11) Feb 24 2004 IMHO, it's rather easy to shut the compiler up (just comment out the
• J C Calvarese (5/17) Feb 24 2004 I don't understand. If they're unused, aren't they just "inert"?
• J Anderson (39/54) Feb 24 2004 ie - C++ (warnings as errors)
• larry cowan (15/72) Feb 24 2004 But then is it going to complain about struct members not used (by this ...
• J Anderson (24/135) Feb 25 2004 C++ does do that. It's not a module or class level thing. It's function...
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (8/34) Feb 25 2004 ... in thread "[Language design] yet another notational error"
• Sean Kelly (6/10) Feb 24 2004 Agreed. I always compile with warnings set at max level and only ignore...
• J Anderson (5/15) Feb 24 2004 In C++ I put push-pop the warning level for every file (it's in my cpp
• C (14/67) Feb 24 2004 I completely agree, fixing the pre-existing code should not be too =
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (14/29) Feb 24 2004 I do agree, and while I've not written large amounts of D code yet, but
• Matthew (10/55) Feb 24 2004 Coulnd't agree more.
• J C Calvarese (40/56) Feb 24 2004 Your post and some of the replied got me thinking...
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
"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
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
"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
```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

That would be a very bad idea performance wise, unless the calculation
is a compile time one (like would be possible with the example given).

--
```
Feb 24 2004
```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
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
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
```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
```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

--
```
Feb 24 2004
```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

--

```
Feb 24 2004
```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.

I think this *feature* could be argued both ways, so IMHO I think it is
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.

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.

-larry

--
```
Feb 24 2004
```In article <c1g8fi\$1978\$1 digitaldaemon.com>, J Anderson says...

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.

I think this *feature* could be argued both ways, so IMHO I think it is
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.

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.

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

--

```
Feb 24 2004
J C Calvarese <jcc7 cox.net> writes:
```J Anderson wrote:

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

--
```
Feb 24 2004
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
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
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
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=

r =

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=

s =

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=

e =

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=

g.

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

e =

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

p =

and it should be fixed.

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

l =

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

--
```
Feb 24 2004
```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

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.

--

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

You would only look at the first 2 or 3 out of the 10. Search-replace
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.

IMHO

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.

--
```
Feb 24 2004
"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
```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?

Generally I use something like rational rose (C++) to build the module,
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

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.

Personally, I wouldn't go that far. I would work on a theme in the
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

--
```
Feb 27 2004
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
```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:
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.

--
```
Feb 24 2004
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
```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.

--

--
```
Feb 24 2004
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

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

--
```
Feb 24 2004
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.

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

--
Justin
http://jcc_7.tripod.com/d/
```
Feb 24 2004
``` - 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
processes" when I'm trying chase down a bug.

IMHO, it's rather easy to shut the compiler up (just comment out the
variables initalizion points).  If you have loose variables around in
debugging code, it can cause more unexpected bugs.

--
```
Feb 24 2004
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
processes" when I'm trying chase down a bug.

IMHO, it's rather easy to shut the compiler up (just comment out the
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
```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
processes" when I'm trying chase down a bug.

IMHO, it's rather easy to shut the compiler up (just comment out the
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"?

ie - C++ (warnings as errors)

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.

--
```
Feb 24 2004
```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

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
processes" when I'm trying chase down a bug.

IMHO, it's rather easy to shut the compiler up (just comment out the
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"?

ie - C++ (warnings as errors)

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.

--

```
Feb 24 2004
```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...

C++ does do that. It's not a module or class level thing.  It's function
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?

It's only very basic logic.  It's not a runtime thing.  If the variable
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

Why use a strongly typed compiler at all then.  You might as well use
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).

Ininitaliztion wouldn't even deal with objects (just ints, floats
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

Sorry I'm not sure where on the same planet here?  This stuff has been
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
processes" when I'm trying chase down a bug.

IMHO, it's rather easy to shut the compiler up (just comment out the
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"?

ie - C++ (warnings as errors)

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.

--

--
```
Feb 25 2004
=?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)?

Cheers,
Sigbjørn Lund Olsen
```
Feb 25 2004
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:

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

--
```
Feb 24 2004
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 =

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

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

--

-- =

Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
```
Feb 24 2004
=?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
"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

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

--

```
Feb 24 2004
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
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
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