"Burton Radons" <loth@users.sourceforge.net> wrote in message news:c1it4t$2tid$1@digitaldaemon.com...
> 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.

You have some good points. One problem with casts is that they can mask bugs because the compiler will do whatever it takes to satisfy the cast. Another problem with doing away with implicit narrowing conversions is:

    char a,b,c;
    c = a + b;

will no longer be valid because of the integral promotion rules. One could say get rid of the integral promotion rules, but then D will have a subtle semantic difference from C:

    a = 128;
    b = 128;
    int i = a + b;    // 256 in C, 0 in D

which is unacceptable. One possibility might be to just disallow implicit narrowing conversions from long to int.

Walter wrote:
> 
> You have some good points. One problem with casts is that they can mask bugs
> because the compiler will do whatever it takes to satisfy the cast. Another
> problem with doing away with implicit narrowing conversions is:
> 
>     char a,b,c;
>     c = a + b;
> 
> will no longer be valid because of the integral promotion rules.

Ouch.  I hadn't thought of this.  I don't think I'd ever want to require a cast when doing same-type operations.

> One could
> say get rid of the integral promotion rules, but then D will have a subtle
> semantic difference from C:
> 
>     a = 128;
>     b = 128;
>     int i = a + b;    // 256 in C, 0 in D
> 
> which is unacceptable. One possibility might be to just disallow implicit
> narrowing conversions from long to int.

Consistency is important for linguistic clarity.  I think this casting rule is something that has to be all or nothing.  In light of the implicit "widening" during expression evaluation, I'd vote to allow implicit "narrowing" as well.  If mistakes are truly a concern and compiler warnings are not an option, a code profiler could still fill the gap.


Sean

> Ouch.  I hadn't thought of this.  I don't think I'd ever want to require a cast when doing same-type operations.

Hmm yea I didnt know it had such far reaching consequenses either.  I really like Manfred's idea, maybe something like std.strict ?

C

On Wed, 25 Feb 2004 14:08:21 -0800, Sean Kelly <sean@ffwd.cx> wrote:

> Walter wrote:
>>
>> You have some good points. One problem with casts is that they can mask bugs
>> because the compiler will do whatever it takes to satisfy the cast. Another
>> problem with doing away with implicit narrowing conversions is:
>>
>>     char a,b,c;
>>     c = a + b;
>>
>> will no longer be valid because of the integral promotion rules.
>
> Ouch.  I hadn't thought of this.  I don't think I'd ever want to require a cast when doing same-type operations.
>
>> One could
>> say get rid of the integral promotion rules, but then D will have a subtle
>> semantic difference from C:
>>
>>     a = 128;
>>     b = 128;
>>     int i = a + b;    // 256 in C, 0 in D
>>
>> which is unacceptable. One possibility might be to just disallow implicit
>> narrowing conversions from long to int.
>
> Consistency is important for linguistic clarity.  I think this casting rule is something that has to be all or nothing.  In light of the implicit "widening" during expression evaluation, I'd vote to allow implicit "narrowing" as well.  If mistakes are truly a concern and compiler warnings are not an option, a code profiler could still fill the gap.
>
>
> Sean
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

One more vote for explicit casting.  Narrowing conversions
should always need casting.  Pros 1) marginal amount of work on the
part of the programmer and 2) added clarity at the source code
level.  A less tangible benefit is that it is philosophically in line with
a strongly typed language, which I imagine most people here agree
with (i.e. that strong types are good).

Cheers.



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

Requiring a cast isn't that much work and it signifies beyond doubt that the programmer intends for this narrowing to occur.  Besides, type conversions shouldn't be that frequent.

 -- andy

On Wed, 25 Feb 2004 10:44:46 -0800 (02/26/04 05:44:46)
, Walter <walter@digitalmars.com> 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 have no problem with D performing 'data-loss' type casts implictly, so long as it tells me where its doing it. In such cases I would then alter my code to make explict casts or write it differently.

-- 
Derek

Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:c1it4t$2tid$1@digitaldaemon.com...
> 
>>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.
> 
> 
> You have some good points. One problem with casts is that they can mask bugs
> because the compiler will do whatever it takes to satisfy the cast. Another
> problem with doing away with implicit narrowing conversions is:
> 
>     char a,b,c;
>     c = a + b;
> 
> will no longer be valid because of the integral promotion rules. One could
> say get rid of the integral promotion rules, but then D will have a subtle
> semantic difference from C:
> 
>     a = 128;
>     b = 128;
>     int i = a + b;    // 256 in C, 0 in D
> 
> which is unacceptable. One possibility might be to just disallow implicit
> narrowing conversions from long to int.

That would get ugly too. Guess I should think longer and type later :-/
I'm a bit in doubt now. I can see how it'll get difficult separating the cases where implicit conversion works to the advantage of the programmer and the cases where it's a source of bugs.

Cheers,
Sigbjørn Lund Olsen

"Walter" <walter@digitalmars.com> wrote in message news:c1j4d8$8nd$2@digitaldaemon.com...
>
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:c1it4t$2tid$1@digitaldaemon.com...
> > 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.
>
> You have some good points. One problem with casts is that they can mask
bugs
> because the compiler will do whatever it takes to satisfy the cast.
Another
> problem with doing away with implicit narrowing conversions is:

Then provide a narrowing_cast() operator

>     char a,b,c;
>     c = a + b;
>
> will no longer be valid because of the integral promotion rules. One could say get rid of the integral promotion rules, but then D will have a subtle semantic difference from C:
>
>     a = 128;
>     b = 128;
>     int i = a + b;    // 256 in C, 0 in D
>
> which is unacceptable. One possibility might be to just disallow implicit narrowing conversions from long to int.

Tricky stuff, to be sure. Is it really not possible to have the compiler deduce the correct promotion in the previous two cases? Probably you could provide examples of pathological cases, though ...

"Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:c1jd25$ogj$1@digitaldaemon.com...
> Walter wrote:
> > "Burton Radons" <loth@users.sourceforge.net> wrote in message news:c1it4t$2tid$1@digitaldaemon.com...
> >
> >>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.
> >
> >
> > You have some good points. One problem with casts is that they can mask
bugs
> > because the compiler will do whatever it takes to satisfy the cast.
Another
> > problem with doing away with implicit narrowing conversions is:
> >
> >     char a,b,c;
> >     c = a + b;
> >
> > will no longer be valid because of the integral promotion rules. One
could
> > say get rid of the integral promotion rules, but then D will have a
subtle
> > semantic difference from C:
> >
> >     a = 128;
> >     b = 128;
> >     int i = a + b;    // 256 in C, 0 in D
> >
> > which is unacceptable. One possibility might be to just disallow
implicit
> > narrowing conversions from long to int.
>
> That would get ugly too. Guess I should think longer and type later :-/ I'm a bit in doubt now. I can see how it'll get difficult separating the cases where implicit conversion works to the advantage of the programmer and the cases where it's a source of bugs.

Indeed, but since D does not provide warnings, I don't see we're left with much of a choice. Leaving it implicit with no warning is a recipe for disaster. I see four possibilities:

1. Status quo: Implicit, no warnings. A wise man once said this was a recipe
for disaster
2. Implicit, warnings. Walter don't like warnings, and if we can get D to
1.0 without a genuine need for warnings, I think we'll be very happy.
3. Explicit, no warnings. Very tedious coding. Will put off huge amounts of
people, since we're all lazy f**kers, when you boil it down. It's just too
nannying.
4. Explict/Implicit in an informed manner, no warnings. In the above two
cases, the compiler would do the "right thing", but would still reject
pathological narrowing. The problem here is that I don't doubt that there'll
be awkward cases. Maybe such non-obvious cases should just wear the casts.

[btw, I think Walter's right about the cast doing other things, so I suggest a narrow_cast() operator. It's extra ugliness is a good thing, IMO.]

1 is a no-go, IMO
2 is probably the most practical one, but will lose the no-warnings caché
3 is a no-go, IMO
4 is the most ideal, but is a lot of work in language rules and compiler
writing. Still, if he doesn't want warnings ...


My two cents

Cheers

Matthew

Matthew wrote:

[...]
> 4. Explict/Implicit in an informed manner, no warnings.
[...]

What about getting rid of casts for assignments at all? Why not implement two assignment operators, for example `=' and `:='?

One requires lhs and rhs to be of the same type, while the other requires lhs and rhs to be of different types.

Then the first requires an explicit cast when lhs and rhs are different. Whereas the second introduces the cast implicitely and at the same time flags, that the coder was aware of the fact that lhs and rhs differ.

Example:

char a, b, c;
int i;

c= a + b;  // okay
c:= a + b; // error: use = to assign equal types

i= cast(int)( a + b ); // okay
i= a + b;              // error: use := to assign unequal types
i:= a + b;             // okay

So long.