www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newbie: implicit conversions

reply ano <ano_member pathlink.com> writes:
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
parent reply 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
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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:




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

Jill
Oct 06 2004
next sibling parent ano <ano_member pathlink.com> writes:
In article <ck0jc5$25hm$1 digitaldaemon.com>, Arcane Jill says...




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
prev sibling next sibling parent 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:
 


 
 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
prev sibling next sibling parent 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:
 


 
 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
prev sibling parent reply 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:




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


I've had a change of heart about this, mostly for practical reasons (credit goes
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:




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:



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
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Sean Kelly wrote:
<snip>

 Consider the following:
 


 
 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:
 

 
 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
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <ck347a$14s0$1 digitaldaemon.com>, Stewart Gordon says...

Sean Kelly wrote:
<snip>

 Consider the following:
 


 
 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
prev sibling parent 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