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'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?
>
>

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

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

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.

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.

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.

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

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.

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