View mode: basic / threaded / horizontal-split · Log in · Help
February 25, 2004
Implicit narrowing conversions
At issue is whether implicit narrowing conversions should be allowed, i.e.:

   char c;
   int i;
   c = i;        // i implicitly 'narrowed' to char

This is allowed by D, but it can be a hidden source of bugs. The alternative
would be to
require a cast:

   c = cast(char) i;

Comments?
February 25, 2004
Re: Implicit narrowing conversions
I'd be in favor of requiring an explicit cast.  It would take a while to adjust
to, but in the end it would result in fewer bugs.

Owen

In article <c1iqf1$2oqg$1@digitaldaemon.com>, Walter says...
>
>At issue is whether implicit narrowing conversions should be allowed, i.e.:
>
>    char c;
>    int i;
>    c = i;        // i implicitly 'narrowed' to char
>
>This is allowed by D, but it can be a hidden source of bugs. The alternative
>would be to
>require a cast:
>
>    c = cast(char) i;
>
>Comments?
>
>
February 25, 2004
Re: Implicit narrowing conversions
Walter wrote:

> At issue is whether implicit narrowing conversions should be allowed, i.e.:
> 
>     char c;
>     int i;
>     c = i;        // i implicitly 'narrowed' to char
> 
> This is allowed by D, but it can be a hidden source of bugs. The alternative
> would be to
> require a cast:
> 
>     c = cast(char) i;
> 
> Comments?

c = cast(char)i; is much to be preferred. It's the only way to be sure 
that the cast is actually what the programmer intends to do (and would 
require fairly little effort since the compiler would flag it as an 
error on compile), and would aid in the production of more robust code. 
After all, a compile error is a 10-second nuisance, whereas a logic 
(hidden) bug can keep you occupied for ages...

Cheers,
Sigbjørn Lund Olsen
February 25, 2004
Re: Implicit narrowing conversions
One more vote for the explicit cast(char).

"Walter" <walter@digitalmars.com> wrote in message
news:c1iqf1$2oqg$1@digitaldaemon.com...
> At issue is whether implicit narrowing conversions should be allowed,
i.e.:
>
>     char c;
>     int i;
>     c = i;        // i implicitly 'narrowed' to char
>
> This is allowed by D, but it can be a hidden source of bugs. The
alternative
> would be to
> require a cast:
>
>     c = cast(char) i;
>
> Comments?
>
>
February 25, 2004
Re: Implicit narrowing conversions
Walter wrote:
> At issue is whether implicit narrowing conversions should be allowed, i.e.:
> 
>     char c;
>     int i;
>     c = i;        // i implicitly 'narrowed' to char
> 
> This is allowed by D, but it can be a hidden source of bugs. The alternative
> would be to
> require a cast:
> 
>     c = cast(char) i;
> 
> Comments?
> 
> 
I think that the cast is preferable.  It makes it explicit as to what is 
happening, and doesn't hide any possible loss of data.
February 25, 2004
Re: Implicit narrowing conversions
Walter wrote:
> At issue is whether implicit narrowing conversions should be allowed, i.e.:
> 
>     char c;
>     int i;
>     c = i;        // i implicitly 'narrowed' to char
> 
> This is allowed by D, but it can be a hidden source of bugs. The alternative
> would be to
> require a cast:
> 
>     c = cast(char) i;
> 
> Comments?

In thirteen years of coding C, this has never caused a bug.

What this kind of "bug-fixing" change reminds me of is how the way the 
locks on my truck are setup.  If the door's locked, you have to close it 
with the handle pulled up or else it will unlock itself.  Ostensibly, 
this is to make you think about the keys before doing so, but in 
reality, you just end up doing it automatically; at most you glance at 
the door lock to make sure it didn't pop back up before going on your 
way.  That's all that this will lead to, for those programmers too 
unconscientious to think about what they're doing as they're doing it - 
the ones which this fix are supposed to help.
February 25, 2004
Re: Implicit narrowing conversions
Walter wrote:

[...]
>     c = i;        // i implicitly 'narrowed' to char

What should the semantic of "narrowing" be? Currently an integer casted
to a character yields the character to contain the low order byte of the
integer. Does "narrowing" mean, that `c' contains `char.max' if `i >
char.max'?

> This is allowed by D, but it can be a hidden source of bugs.

Because the specification states, that the assignment contains an implicit
cast all assignments are the object of undivided attention.

> The alternative would be to require a cast:
[...]

There is no reason to force a coder, who already properly checked that the
value of a source integer is in the range of the targeted character type,
at the actual assignment to declare that he now really, really wants to
cast. 

Those who do not trust themselves, or other coders, can typedef the
standard types to `my...' or what else they want, thereby forcing the
requirement of explicitely casting:

typedef int myint:
typedef char mychar;

myint i;
mychar c;

//c= i;  // error:  cannot implicitly convert myint to mychar

Because this may be a system wide requirement, D should support something
like policies, i.e. modules, that are imported automatically and for which
might relaxations of the language be valid. An example for such a policy
could be:

typedef int myint;
alias myint int;

typedef char mychar;
alias mychar char;

Therebye redefining the semantics of `int' and `char' to require explict
casts.

So long.
February 25, 2004
Re: Implicit narrowing conversions
I think it's rare that the original programmer of an application would 
make a mistake with implicit casting, but relying on it makes 
maintenance more difficult.  I would like to see a cast required in this 
case, especially in view of the "warnings are errors" mindset in D.  One 
question: where does this leave implicit evaluation of integers and 
pointers as boolean values?  The "if( pointer );" construct would be 
hard to shake.


Sean
February 25, 2004
Re: Implicit narrowing conversions
Good points Manfred. Your explicit typedef notion 'might' also satisfy some
of the issues in the "Implicit casting" thread but, of course, would depend
on individual programmer thoroughness.

I think Walter's suggestion is more of value for long-term maintenance,
where someone not so astute or well informed might screw things up at a
later date. An explicit cast should at least give 'em a clue, yes?

- Kris


"Manfred Nowak" <svv1999@hotmail.com> wrote in message
news:c1iuq6$3093$1@digitaldaemon.com...
> Walter wrote:
>
> [...]
> >     c = i;        // i implicitly 'narrowed' to char
>
> What should the semantic of "narrowing" be? Currently an integer casted
> to a character yields the character to contain the low order byte of the
> integer. Does "narrowing" mean, that `c' contains `char.max' if `i >
> char.max'?
>
> > This is allowed by D, but it can be a hidden source of bugs.
>
> Because the specification states, that the assignment contains an implicit
> cast all assignments are the object of undivided attention.
>
> > The alternative would be to require a cast:
> [...]
>
> There is no reason to force a coder, who already properly checked that the
> value of a source integer is in the range of the targeted character type,
> at the actual assignment to declare that he now really, really wants to
> cast.
>
> Those who do not trust themselves, or other coders, can typedef the
> standard types to `my...' or what else they want, thereby forcing the
> requirement of explicitely casting:
>
> typedef int myint:
> typedef char mychar;
>
> myint i;
> mychar c;
>
> //c= i;  // error:  cannot implicitly convert myint to mychar
>
> Because this may be a system wide requirement, D should support something
> like policies, i.e. modules, that are imported automatically and for which
> might relaxations of the language be valid. An example for such a policy
> could be:
>
> typedef int myint;
> alias myint int;
>
> typedef char mychar;
> alias mychar char;
>
> Therebye redefining the semantics of `int' and `char' to require explict
> casts.
>
> So long.
February 25, 2004
Re: Implicit narrowing conversions
Manfred Nowak wrote:
>
> What should the semantic of "narrowing" be? Currently an integer casted
> to a character yields the character to contain the low order byte of the
> integer. Does "narrowing" mean, that `c' contains `char.max' if `i >
> char.max'?

I think "narrowing" just means a cast to a smaller-sized value, which 
would work the same as your explanation of an int converted to a char.

> There is no reason to force a coder, who already properly checked that the
> value of a source integer is in the range of the targeted character type,
> at the actual assignment to declare that he now really, really wants to
> cast. 

What if the coder hasn't properly checked the value?  IMO explicit 
casting is an indication to the compiler that the programmer knows he is 
"narrowing" a value.  The only time casting irks me at times is when I'm 
comparing signed and unsigned integers, and even this isn't much of an 
issue.

> Those who do not trust themselves, or other coders, can typedef the
> standard types to `my...' or what else they want, thereby forcing the
> requirement of explicitely casting:

True enough.  This isn't a feature available in C.  And kind of an 
interesting idea, though I'm not sure offhand if doing this at a more 
basic level (like you suggested with policies) would break anything.


Sean
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home