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.

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.

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

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 :)

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.

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

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.

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:

#    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

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.

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

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