## digitalmars.D - newbie: implicit conversions

• ano (8/8) Oct 06 2004 i'm just starting learning D and one thing that i dislike is implicit
• Stewart Gordon (4/12) Oct 06 2004 Walter doesn't like warnings. But yes, this is perhaps a wart in D. It...
• Arcane Jill (7/18) Oct 06 2004 Yes, I agree with Stewart here. Not that I have anything against /lossle...
• ano (6/10) Oct 06 2004 yep, that's why i wrote a double => float conversion as example.
• Stewart Gordon (7/14) Oct 06 2004 Indeed. This was talked about quite extensively:
• Ben Hinkle (12/39) Oct 06 2004 The thing about floating point conversions is that forgetting precision ...
• Stewart Gordon (11/29) Oct 07 2004 Are you sure? I thought that operators like ++ could be applied to any
• Sean Kelly (5/16) Oct 07 2004 They can, but they are effectively evaluated as "b = b + 1," which is an
• Sean Kelly (4/12) Oct 07 2004 Interesting idea. I'll have to think about it for a bit, but my first
```i'm just starting learning D and one thing that i dislike is implicit
conversions
going on silently in the background. e.g.

double d = 1234.5678;
float f = d;  //implicit conversion. possibly dangerous.

i guess, after a long time using MS VisualC++ i'm just so used to it giving me
warnings for such things. maybe i'm just missing some DMD compiler flag?

thanks.
```
Oct 06 2004
Stewart Gordon <smjg_1998 yahoo.com> writes:
```ano wrote:

i'm just starting learning D and one thing that i dislike is implicit
conversions going on silently in the background. e.g.

double d = 1234.5678;
float f = d;  //implicit conversion. possibly dangerous.

i guess, after a long time using MS VisualC++ i'm just so used to it giving me
warnings for such things. maybe i'm just missing some DMD compiler flag?

Walter doesn't like warnings.  But yes, this is perhaps a wart in D.  It
ought to be an error.

Stewart.
```
Oct 06 2004
```In article <ck0hq1\$243q\$1 digitaldaemon.com>, Stewart Gordon says...
ano wrote:

i'm just starting learning D and one thing that i dislike is implicit
conversions going on silently in the background. e.g.

double d = 1234.5678;
float f = d;  //implicit conversion. possibly dangerous.

i guess, after a long time using MS VisualC++ i'm just so used to it giving me
warnings for such things. maybe i'm just missing some DMD compiler flag?

Walter doesn't like warnings.  But yes, this is perhaps a wart in D.  It
ought to be an error.

Yes, I agree with Stewart here. Not that I have anything against /lossless/
implicit conversions. For example, the following is fine by me:

#    float f = 1234.5678;
#    double d = f;

But /lossy/ conversions should never (IMO) be implicit. This is just bad news.

Jill
```
Oct 06 2004
```In article <ck0jc5\$25hm\$1 digitaldaemon.com>, Arcane Jill says...
#    float f = 1234.5678;
#    double d = f;

But /lossy/ conversions should never (IMO) be implicit. This is just bad news.

Jill

yep, that's why i wrote a double => float conversion as example.

a signed/unsigned conversion in D should perhaps only spit out a warning instead
of an error. an error would only get in your way because often the conversion is
simply not avoidable (IMHO). i probably couldn't even write 10 lines of C++ STL
code if conversion from size_t to int would be an error :)
```
Oct 06 2004
Stewart Gordon <smjg_1998 yahoo.com> writes:
```Arcane Jill wrote:
<snip>
Yes, I agree with Stewart here. Not that I have anything against /lossless/
implicit conversions. For example, the following is fine by me:

#    float f = 1234.5678;
#    double d = f;

But /lossy/ conversions should never (IMO) be implicit. This is just bad news.

Indeed.  This was talked about quite extensively:

http://www.digitalmars.com/drn-bin/wwwnews?D/24706

Of course, as was said back then, narrowing back from default promotions
should remain implicit.

Stewart.
```
Oct 06 2004
Ben Hinkle <bhinkle4 juno.com> writes:
```Arcane Jill wrote:

In article <ck0hq1\$243q\$1 digitaldaemon.com>, Stewart Gordon says...
ano wrote:

i'm just starting learning D and one thing that i dislike is implicit
conversions going on silently in the background. e.g.

double d = 1234.5678;
float f = d;  //implicit conversion. possibly dangerous.

i guess, after a long time using MS VisualC++ i'm just so used to it
giving me warnings for such things. maybe i'm just missing some DMD
compiler flag?

Walter doesn't like warnings.  But yes, this is perhaps a wart in D.  It
ought to be an error.

Yes, I agree with Stewart here. Not that I have anything against
/lossless/ implicit conversions. For example, the following is fine by me:

#    float f = 1234.5678;
#    double d = f;

But /lossy/ conversions should never (IMO) be implicit. This is just bad
news.

Jill

The thing about floating point conversions is that forgetting precision can
actually make more sense than making up false precision. An integer is a
precise value so adding more bits doesn't hurt but for floating point the
value is not precise (of course to the computer it is precise but the whole
point of floating point is that it has a finite precision) so adding bits
is making up information out of the blue. For example if I am storing pi as
a float and convert it to double it isn't close to pi as a double. But if I
have pi as a double and convert to float I still have a value close to pi
(in the given precision). However that argument doesn't apply all the time
since I can have 1 as a float and convert it to double just fine.

-Ben
```
Oct 06 2004
Sean Kelly <sean f4.ca> writes:
```In article <ck0jc5\$25hm\$1 digitaldaemon.com>, Arcane Jill says...
In article <ck0hq1\$243q\$1 digitaldaemon.com>, Stewart Gordon says...
ano wrote:

i'm just starting learning D and one thing that i dislike is implicit
conversions going on silently in the background. e.g.

double d = 1234.5678;
float f = d;  //implicit conversion. possibly dangerous.

i guess, after a long time using MS VisualC++ i'm just so used to it giving me
warnings for such things. maybe i'm just missing some DMD compiler flag?

Walter doesn't like warnings.  But yes, this is perhaps a wart in D.  It
ought to be an error.

Yes, I agree with Stewart here. Not that I have anything against /lossless/
implicit conversions. For example, the following is fine by me:

#    float f = 1234.5678;
#    double d = f;

But /lossy/ conversions should never (IMO) be implicit. This is just bad news.

to "The Design and Evolution of C++" for explaining the problems so clearly).
While I don't like implicit narrowing conversions, I think they may be a
necessary evil.  Consider the following:

#    byte b = 1;
#    ++b;

Seems fine, no?  Except b is converted to an int for the increment and converted
back for the assignment, so this would have to be rewritten as:

#    b = cast(byte)( b + 1 );

And what if b were equal to BYTE_MAX rather than 1 before the increment?  The
result would be an overflow but the explicit cast would likely suppress any
error that might otherwise be generated.

I suppose we could resurrect the suggestion that type promotion be made to the
largest type in the expression rather than automatically to int, but I'm not
sure this would be technically possible on all platforms (and it may also hurt
performance).

Sean
```
Oct 06 2004
Stewart Gordon <smjg_1998 yahoo.com> writes:
```Sean Kelly wrote:
<snip>
Consider the following:

#    byte b = 1;
#    ++b;

Seems fine, no?  Except b is converted to an int for the increment and
converted
back for the assignment,

Are you sure?  I thought that operators like ++ could be applied to any
numeric type.

so this would have to be rewritten as:

#    b = cast(byte)( b + 1 );

And what if b were equal to BYTE_MAX rather than 1 before the increment?  The
result would be an overflow but the explicit cast would likely suppress any
error that might otherwise be generated.

But it's behaving, in terms of the type of the variable, the same way as
an int or any other integral type would.

I suppose we could resurrect the suggestion that type promotion be made to the
largest type in the expression rather than automatically to int, but I'm not
sure this would be technically possible on all platforms (and it may also hurt
performance).

I think the 'looks like C, acts like C' mindset was one of the motives
against this.

I suggested a neat way of dealing with it a while back:

http://www.digitalmars.com/drn-bin/wwwnews?D/24979

Stewart.
```
Oct 07 2004
Sean Kelly <sean f4.ca> writes:
```In article <ck347a\$14s0\$1 digitaldaemon.com>, Stewart Gordon says...
Sean Kelly wrote:
<snip>
Consider the following:

#    byte b = 1;
#    ++b;

Seems fine, no?  Except b is converted to an int for the increment and
converted
back for the assignment,

Are you sure?  I thought that operators like ++ could be applied to any
numeric type.

They can, but they are effectively evaluated as "b = b + 1," which is an
expression.  As far as I know, all (sub-dword) integral types are automatically
ptomoted to integers for expression evaluation.

Sean
```
Oct 07 2004
Sean Kelly <sean f4.ca> writes:
```In article <ck347a\$14s0\$1 digitaldaemon.com>, Stewart Gordon says...
I suppose we could resurrect the suggestion that type promotion be made to the
largest type in the expression rather than automatically to int, but I'm not
sure this would be technically possible on all platforms (and it may also hurt
performance).

I think the 'looks like C, acts like C' mindset was one of the motives
against this.

I suggested a neat way of dealing with it a while back:

http://www.digitalmars.com/drn-bin/wwwnews?D/24979

Interesting idea.  I'll have to think about it for a bit, but my first
inclination is that it's a good suggestion.

Sean
```
Oct 07 2004