www.digitalmars.com         C & C++   DMDScript  

D - Implicit narrowing conversions

reply "Walter" <walter digitalmars.com> writes:
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?
Feb 25 2004
next sibling parent resistor mac.com writes:
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?
Feb 25 2004
prev sibling next sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Feb 25 2004
prev sibling next sibling parent "Kris" <someidiot earthlink.net> writes:
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?
Feb 25 2004
prev sibling next sibling parent Steve Adams <adamss ascinet.com> writes:
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.
Feb 25 2004
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Feb 25 2004
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Feb 25 2004
next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
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
Feb 25 2004
parent C <dont respond.com> writes:
 Ouch.  I hadn't thought of this.  I don't think I'd ever want to requi=


re =


 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 ma=




sk =


 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 =3D 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 requi=


re =


 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 =3D 128;
     b =3D 128;
     int i =3D 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/
Feb 25 2004
prev sibling next sibling parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Feb 25 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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
Feb 25 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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.
Feb 25 2004
next sibling parent reply "Kris" <someidiot earthlink.net> writes:
That's neat. I like it!

However, isn't there more at stake than that? Consider the implicit cast
used when passing an expression as a method-argument.

- Kris

"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:c1jm26$17gr$1 digitaldaemon.com...

 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.
Feb 25 2004
parent reply Juan C <Juan_member pathlink.com> writes:
Nah, I expect many would always use the := operator, and wind up in the same
situation.

In article <c1jmcv$1852$1 digitaldaemon.com>, Kris says...

That's neat. I like it!

However, isn't there more at stake than that? Consider the implicit cast
used when passing an expression as a method-argument.

- Kris

"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:c1jm26$17gr$1 digitaldaemon.com...

 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.
Feb 25 2004
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
On Thu, 26 Feb 2004 02:53:42 +0000, Juan C wrote:

[...]

 and wind up in the same situation.


You know about programs where all assignments are of different types?

So long.
Feb 25 2004
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Juan C wrote:


 always use the := operator


Extension especially for you:

introduction of a third assignment operator, the potential lossy
assignment operator `::='. It requires lhs and rhs to be of different
types and 
`typeof(lhs).min > typeof(rhs).min || typeof(lhs).max < typeof(rhs).max'

At the same time the `:=' operator is only legal when
`!(typeof(lhs).min > typeof(rhs).min || typeof(lhs).max < typeof(rhs).max)'

Example:

char a, b, c;
int i;

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

i= cast(int)( a + b ); // okay, but old style
i= a + b;              // error: use := or ::= to assign unequal types
i:= a + b;             // okay
i::= a + b;            // error: use := for data preserving assignments 

c= cast(char)i;        // okay, but old style
c:= i;                 // error: use ::= for potential lossy assignments
c::= i;                // okay

So long.
Feb 25 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
This is getting really really funny!

We also need a set of type deduction assignment operators:

:::=	- LHS is declared to be of the exact type of the RHS
::::=	- LHS is declared to be of a random supertype of the RHS

and then a few comparison operators:

==:	- comparison by value with atomatic casting of both sides to 
something compatible
===:	- ditto for comparison by reference
then !=:, <>:, <:, ... and all the others as well!

-eye

Manfred Nowak wrote:


 Juan C wrote:
 
 

always use the := operator


 
 
 Extension especially for you:
 
 introduction of a third assignment operator, the potential lossy
 assignment operator `::='. It requires lhs and rhs to be of different
 types and 
 `typeof(lhs).min > typeof(rhs).min || typeof(lhs).max < typeof(rhs).max'
 
 At the same time the `:=' operator is only legal when
 `!(typeof(lhs).min > typeof(rhs).min || typeof(lhs).max < typeof(rhs).max)'
 
 Example:
 
 char a, b, c;
 int i;
 
 c= a + b;   // okay
 c:= a + b;  // error: use = to assign equal types
 c::= a + b; // error: use = to assign equal types
 
 i= cast(int)( a + b ); // okay, but old style
 i= a + b;              // error: use := or ::= to assign unequal types
 i:= a + b;             // okay
 i::= a + b;            // error: use := for data preserving assignments 
 
 c= cast(char)i;        // okay, but old style
 c:= i;                 // error: use ::= for potential lossy assignments
 c::= i;                // okay
 
 So long.
Feb 26 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
Ilya Minkov wrote:

[...]

 ::::=	- LHS is declared to be of a random supertype of the RHS


[...]

rotfl

At least Juan may be convinced, that then not everybody is always using
the same operator.

so long.
Feb 27 2004
prev sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Manfred Nowak wrote:

 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.


Good idea, but what about when implicit conversions are done to fit 
function parameters (which it does atm, afaik)?

Cheers,
Sigbjørn Lund Olsen
Feb 26 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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 ...
Feb 25 2004
prev sibling next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:c1it4t$2tid$1 digitaldaemon.com...


[...]

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




To me it caused some troubles, mainly from sources made by others.


 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.




I disagree:
- Locking a door is something you do automatically, without actually thinking
about what you are doing, often thinking to soething else. Programming is
supposed to be done with the programmer attention focused on the program.
- Unconscientious programmers can hurt themselves in so many ways that, IMO, is
not worth thinking at them when designing a language.

In article <c1j4d8$8nd$2 digitaldaemon.com>, Walter says...

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.


YES! That's why I think C implicit narrowing casts are bad.
I also think that implicit sign casts are bad.


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.


There are obvious solutions:

- don't use chars for math
- don't use chars to do math that exceeds char's bounds (as you normally don't
use int math that exceeds int's bounds). An OverflowException here could help,
we discussed about this some time ago.
- Throw away your old badly-written C code.


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


Why?
I'd dissallow implicit narrowing conversion from floating point to int, instead.

IMHO narrowing casts (and sign casts) should be handled with care, not simply
doing cast(something) expression:

little_int l;
big_int b;

l = extract_bits(b); // old C bad way

l = saturate(b);     // if (b > little_int.max) l = little_int.max 
// if (b < little_int.min) l = little_int.min

l = precise(b);      // if (b < little_int.min || b > little_int.max) 
//   throw NarrowCastException;

unsigned_little_int u;

b = -1;
u = extract_bits(b); // u = unsigned_little_int.max
u = saturate(b);     // u = 0
u = precise(b);      // throw NarrowCastException

any_float f;
any_int i;

i = saturate(f);     // same as before
i = precise(f);      // f must be an integer of the rignt range
i = floor(f);
i = round(f);
i = ceil(f);

I know theese functions can be user defined, but I think it's better to help the
user to use them, disallowing implicit narrowing conversions.

Ciao
Feb 26 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
Roberto Mariottini wrote:


 IMHO narrowing casts (and sign casts) should be handled with care, not simply
 doing cast(something) expression:
 
 [... more code ...]
 i = saturate(f);     // same as before
 i = precise(f);      // f must be an integer of the rignt range
 i = floor(f);
 i = round(f);
 i = ceil(f);
 
 I know theese functions can be user defined, but I think it's better to help
the
 user to use them, disallowing implicit narrowing conversions.


There's a big catch to this approach due to the way function overloading 
works.  For any one input type, someone could want to convert to any 
number of types.  So you'd need methods like saturateToFloat, (or some 
templating) which gets a little on the verbose side.

Aside from that, it's an elegant solution.  No extra syntax needs to be 
added to the language, and what the code is doing is crystal clear.

  -- andy
Feb 26 2004
prev sibling parent Sean Kelly <sean ffwd.cx> writes:
Roberto Mariottini wrote:

 
 There are obvious solutions:
 
 - don't use chars for math


If there were a byte type then I wouldn't mind this, otherwise forget it.


 - don't use chars to do math that exceeds char's bounds (as you normally don't
 use int math that exceeds int's bounds). An OverflowException here could help,
 we discussed about this some time ago.


This would be fine, though it gives rise to some odd problems.  What if 
I do this:

char c = 1;
c <<= 10;

Overflow from bit shifting can be a desired effect.  I certainly wouln't 
want to have an exception thrown.


 - Throw away your old badly-written C code.


Works for me.



 b = -1;
 u = extract_bits(b); // u = unsigned_little_int.max
 u = saturate(b);     // u = 0
 u = precise(b);      // throw NarrowCastException


Ugh.  So I have to wait until run time to find out I'd done something 
illegal?  And this is something that could have been detected at compile 
time?  Overflow errors are one thing, but this is a bit extreme.


 I know theese functions can be user defined, but I think it's better to help
the
 user to use them, disallowing implicit narrowing conversions.


That still doesn't address the integer promotion issue.  Should the 
compiler perhaps continue to allow implicit casting as a result of 
integer promotion if the widest involved type in the expression is 
smaller than or equal to the size of the result type?  ie.

char c1, c2, c3;
short s1, s2, s3;
unsigned u1;
float f1;

c1 = c2 + c3; // legal
c1 = c2 + s3; // illegal, s3 is wider than c1
s1 = c2 + s3; // legal
u1 = u1 + f1; // equal byte sizes but one is float

What should be done about the last case?  Should implicit conversion 
from float to int be allowed?


Sean
Feb 26 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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. 


I think I know what you mean here but I can't think of any good 
examples, anyone?


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. 


Why not make this kinda situation implicit?  I mean from the viewers 
point of view (most of the time) it is simply the addition of two 
characters.


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.
  


Then user should be force to cast to int.

ie
//if the user wanted 256
char a, b;
int i = (int) (a + b); //Even though a and b would really be using 
integer maths anyway.

//if the user wanted 0
int i = (int) ((byte) a + (byte) b);

Or parhaps
int i = (int) a + (byte) b; //b is added using byte addion and then it's 
converted to an int
or
int i = (byte) a + (byte) b; //implicit conversion from a cast byte

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 26 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
J Anderson 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.


 I think I know what you mean here but I can't think of any good 
 examples, anyone?



Just thought of one:

//module 1
char getValue() {...}

//module 2

class A {}

A getValue() {...}

void func()
{
    int x = (int) getValue(); //Calls the wrong version, converting the 
reference A into an int
}

Of course in this case using the suggested narrow (suggested by Munch) 
would solve the problem.

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 26 2004
prev sibling next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Burton Radons wrote:


 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.



I don't agree. Most of the time you stick within the same type of 
variable so casting isn't an issue.  So you will need to think when 
making a conversion, and it won't become automatic.  Anyway conversion 
can be a performace hazzered so you need to reduce these as much as 
possible.

Although there are the cases when a user may want to write a 
function/method for more then one type but this is where templates are 
useful because they explicitly say - I want to use this function for 
more then one type.  We need to be able to create method templates for 
this reason.

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 26 2004
prev sibling next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Burton Radons wrote:


 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.


Another thing that bothers me about this statement:

You could use this argument to argue against static type checking 
altogether.  Do you not support static type checking for objects?

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 26 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Nice to see you Burton!

You are right, but at least even if it's not informative to the original 
coder, a written-out cast serves as documentation for the people reading 
this source afterwards. Implicit casts take a very long time to see.

So i vote to requiere explicit narrowing casts.

-eye

Burton Radons wrote:


 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.
Feb 26 2004
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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.
Feb 25 2004
next sibling parent "Kris" <someidiot earthlink.net> writes:
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.
Feb 25 2004
prev sibling parent reply Sean Kelly <sean ffwd.cx> writes:
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
Feb 25 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
Sean Kelly wrote:

[...]

 if doing this at a more basic level (like you suggested with policies)
 would break anything. 


I retreat from my suggestions of policies. This might lead to system isles.

So long.
Mar 06 2004
prev sibling next sibling parent Sean Kelly <sean ffwd.cx> writes:
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
Feb 25 2004
prev sibling next sibling parent reply "Andres Rodriguez" <rodriguez ai.sri.com> writes:
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?
Feb 25 2004
parent reply "=?iso-8859-1?Q?Robert_M._M=FCnch?=" <robert.muench robertmuench.de> writes:
On Wed, 25 Feb 2004 15:13:31 -0800, Andres Rodriguez  
<rodriguez ai.sri.com> wrote:


 One more vote for explicit casting.


Hi, I agree but how about:

	uint a = 123456789;
	ubyte b;
	b = narrow(a);

and than let the compiler apply the default rule as it does at the moment.  
Casting is to me a much rougher action than narrowing. The narrow will  
state that I know what I'm doing. Robert
Feb 26 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Robert M. Münch wrote:


 On Wed, 25 Feb 2004 15:13:31 -0800, Andres Rodriguez  
 <rodriguez ai.sri.com> wrote:


 One more vote for explicit casting.



 Hi, I agree but how about:

     uint a = 123456789;
     ubyte b;
     b = narrow(a);

 and than let the compiler apply the default rule as it does at the 
 moment.  Casting is to me a much rougher action than


You do still mean that the narrow word is required?


 narrowing. The narrow will  state that I know what I'm doing. Robert


This is a good idea. I think it overcomes one of the problems Walter 
mentioned before.

Walter:


One problem with casts is that they can mask bugs
because the compiler will do whatever it takes to satisfy the cast. 


Another advantage is it's grepable, so you could easily stop these if 
trying to optimise narrowing conversions.

However I would prefer a shorter term then narrow.

Humm, what-about:
trim()
clip()
cut()

I'm sure there are better terms, smaller terms, although narrow is ok.

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 26 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
I think narrow is an excellent keyword: it's a balance between uniqueness,
ugliness and typeability.

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c1l6ns$nb8$1 digitaldaemon.com...

 Robert M. Münch wrote:


 On Wed, 25 Feb 2004 15:13:31 -0800, Andres Rodriguez
 <rodriguez ai.sri.com> wrote:


 One more vote for explicit casting.



 Hi, I agree but how about:

     uint a = 123456789;
     ubyte b;
     b = narrow(a);

 and than let the compiler apply the default rule as it does at the
 moment.  Casting is to me a much rougher action than


 You do still mean that the narrow word is required?


 narrowing. The narrow will  state that I know what I'm doing. Robert


 This is a good idea. I think it overcomes one of the problems Walter
 mentioned before.

 Walter:


One problem with casts is that they can mask bugs
because the compiler will do whatever it takes to satisfy the cast.


 Another advantage is it's grepable, so you could easily stop these if
 trying to optimise narrowing conversions.

 However I would prefer a shorter term then narrow.

 Humm, what-about:
 trim()
 clip()
 cut()

 I'm sure there are better terms, smaller terms, although narrow is ok.

 -- 
 -Anderson: http://badmama.com.au/~anderson/
Feb 26 2004
prev sibling next sibling parent Sean Kelly <sean ffwd.cx> writes:
Robert M. Münch wrote:

 
 Hi, I agree but how about:
 
     uint a = 123456789;
     ubyte b;
     b = narrow(a);
 
 and than let the compiler apply the default rule as it does at the 
 moment.  Casting is to me a much rougher action than narrowing. The 
 narrow will  state that I know what I'm doing.


I agree.  If we're going to restrict implicit narrowing then a narrow 
cast with the above semantics is a good idea.


Sean
Feb 26 2004
prev sibling next sibling parent "Kris" <someidiot earthlink.net> writes:
This shows promise as it handles the argument-passing case also. Plus, it's
really hard to overlook during routine maintenance, *and* it's easy to find
all these special-cases with a grep :-)

You might consider applying the verb "demote" instead of  "narrow".

- Kris


"Robert M. Münch" <robert.muench robertmuench.de> wrote in message
news:opr3zg6xv3heztw6 news.digitalmars.com...

 On Wed, 25 Feb 2004 15:13:31 -0800, Andres Rodriguez
 <rodriguez ai.sri.com> wrote:


 One more vote for explicit casting.


 Hi, I agree but how about:

 uint a = 123456789;
 ubyte b;
 b = narrow(a);

 and than let the compiler apply the default rule as it does at the moment.
 Casting is to me a much rougher action than narrowing. The narrow will
 state that I know what I'm doing. Robert
Feb 26 2004
prev sibling next sibling parent Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Thu, 26 Feb 2004 16:26:47 +0100 (02/27/04 02:26:47)
, Robert M. Münch <robert.muench robertmuench.de> wrote:


 On Wed, 25 Feb 2004 15:13:31 -0800, Andres Rodriguez  
 <rodriguez ai.sri.com> wrote:


 One more vote for explicit casting.


 Hi, I agree but how about:

 	uint a = 123456789;
 	ubyte b;
 	b = narrow(a);

 and than let the compiler apply the default rule as it does at the 
 moment.  Casting is to me a much rougher action than narrowing. The 
 narrow will  state that I know what I'm doing. Robert


Yes, this will do nicely. Whether its 'narrow' or something else is not 
the point. What is important is that both the compiler and the coder are 
made explicitly aware of what is being attempted. This will reduce 
'surprises' (a.k.a. bugs). It also makes it easy for an implementation of 
D to have this as a runtime-behaviour (a 'D' interpreter for example).

-- 
Derek
Feb 26 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Robert M. Münch wrote:


 On Wed, 25 Feb 2004 15:13:31 -0800, Andres Rodriguez  
 <rodriguez ai.sri.com> wrote:


 One more vote for explicit casting.



 Hi, I agree but how about:

     uint a = 123456789;
     ubyte b;
     b = narrow(a);

 and than let the compiler apply the default rule as it does at the 
 moment.  Casting is to me a much rougher action than narrowing. The 
 narrow will  state that I know what I'm doing. Robert



If this was implemented, should explicit narrow casting still be allowed 
also?
My guess is that explicit narrow casting will still be nessary and it 
would be a matter of advocating *narrow* as best practice.


-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 28 2004
parent reply "=?iso-8859-1?Q?Robert_M._M=FCnch?=" <robert.muench robertmuench.de> writes:
On Sat, 28 Feb 2004 22:36:19 +0800, J Anderson  
<REMOVEanderson badmama.com.au> wrote:


 If this was implemented, should explicit narrow casting still be allowed  
 also?
 My guess is that explicit narrow casting will still be nessary and it  
 would be a matter of advocating *narrow* as best practice.


Hi, sorry I don't get it. What I suggested is explict narrow casting with  
an implicit implementation. It's not stating anything about what to do,  
only that it's OK. It's like an enabler for the compiler to do what it  
does at the moment but with explict OK from the programmer. The only  
purpose it to be sure that the downsizing isn't by accident.

Or did you meant something different?

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de
Feb 28 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Robert M. Münch wrote:


 On Sat, 28 Feb 2004 22:36:19 +0800, J Anderson  
 <REMOVEanderson badmama.com.au> wrote:


 If this was implemented, should explicit narrow casting still be 
 allowed  also?
 My guess is that explicit narrow casting will still be nessary and 
 it  would be a matter of advocating *narrow* as best practice.



 Hi, sorry I don't get it. What I suggested is explict narrow casting 
 with  an implicit implementation. It's not stating anything about what 
 to do,  only that it's OK. It's like an enabler for the compiler to do 
 what it  does at the moment but with explict OK from the programmer. 
 The only  purpose it to be sure that the downsizing isn't by accident.

 Or did you meant something different?


Nar, I understand that. What I mean is:

   char c;
   int i;
   c = narrow(i);  

But we will probably still need explicit narrow casting:

   char c;
   int i;
   c = (char) i;  

So both:

   c = (char) i;  

      c = narrow(i);

would be valid.

Or don't we need explicit narrow (ie not using the narrow word) cast at 
all?

 It's an issue that probably need to be discussed anyway.

IMHO: I think you'll still need normal narrow casting (cast) but in most 
cases the programmer will be able to use *narrow()*.

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 28 2004
parent "=?iso-8859-1?Q?Robert_M._M=FCnch?=" <robert.muench robertmuench.de> writes:
On Sat, 28 Feb 2004 23:10:42 +0800, J Anderson  
<REMOVEanderson badmama.com.au> wrote:


 Nar, I understand that. What I mean is:

    char c;
    int i;
    c = narrow(i);  But we will probably still need explicit narrow  
 casting:

    char c;
    int i;
    c = (char) i;  So both:

    c = (char) i;        c = narrow(i);

 would be valid.


Hi, I stumbled about your wording "narrow casting". To me casting is  
changing types explicit, and narrow using the default action taken by the  
compiler.


 Or don't we need explicit narrow (ie not using the narrow word) cast at  
 all?


Yes, normal casting is still available but it's something different than  
narrow.

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de
Feb 29 2004
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
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
Feb 25 2004
prev sibling next sibling parent Derek Parnell <Derek.Parnell Psyc.ward> writes:
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
Feb 25 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Vote for explicit casting.  The programmer needs to explicitly mention 
his intentions.  I think the code will be wrong most of the time and 
need fixing (how often do we use narrowing anyways?).

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 25 2004
parent Juan C <Juan_member pathlink.com> writes:
In article <c1k66n$212i$1 digitaldaemon.com>, J Anderson says...

Vote for explicit casting.  The programmer needs to explicitly mention 
his intentions.  I think the code will be wrong most of the time and 
need fixing (how often do we use narrowing anyways?).

-- 
-Anderson: http://badmama.com.au/~anderson/


Hear hear.
Feb 26 2004
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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?


Take another vote.

In at least some C/C++ compilers, the warning is "conversion may lose 
significant digits", and quite sensibly.

If you're going to stay true to your 'no warnings' philosophy, you 
should make them errors, rather than getting rid of them altogether.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Feb 26 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>

 Take another vote.
 
 In at least some C/C++ compilers, the warning is "conversion may lose 
 significant digits", and quite sensibly.
 
 If you're going to stay true to your 'no warnings' philosophy, you 
 should make them errors, rather than getting rid of them altogether.


Just thinking about it, one kind of implicit narrowing conversion should 
be allowed, and that is converting an expression back to the type of the 
operands after default promotion.  So we'd have:

byte b;
short s1, s2;
int i;

// the following would be legal
s2 = b + s1;
s2 += b;
s2 += s1;
s2 += cast(short) (b + i);
s2 = s1 + cast(short) (b + i);

// the following would be illegal
s1 = i;
s1 = b + i;
s1 = cast(int) (b + s1);


The compiler would keep track of two types for each subexpression.  The 
base type, and the promoted type.  Calculations would use the promoted 
type as before; implicit narrowing conversions would be allowed down to 
the base type.

Subexpression           Base type       Promoted type
b                       byte            int
s1                      short           int
b + s1                  short           int
i                       int             int
b + i                   int             int
cast(short) (b + i)     short           int
s1 + cast(short) (b+i)  short           int
cast(int) (b + s1)      int             int

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 01 2004
parent reply larry cowan <larry_member pathlink.com> writes:
In article <c1v7nk$to$1 digitaldaemon.com>, Stewart Gordon says...

Stewart Gordon wrote:
<snip>

 Take another vote.
 
 In at least some C/C++ compilers, the warning is "conversion may lose 
 significant digits", and quite sensibly.
 
 If you're going to stay true to your 'no warnings' philosophy, you 
 should make them errors, rather than getting rid of them altogether.


Just thinking about it, one kind of implicit narrowing conversion should 
be allowed, and that is converting an expression back to the type of the 
operands after default promotion.  So we'd have:

byte b;
short s1, s2;
int i;

// the following would be legal
s2 = b + s1;
s2 += b;
s2 += s1;
s2 += cast(short) (b + i);
s2 = s1 + cast(short) (b + i);

// the following would be illegal
s1 = i;
s1 = b + i;
s1 = cast(int) (b + s1);


Where does "s += i" fit?  What about "s += (f * d * r)"? Doesn't that
look a bit out of line?


The compiler would keep track of two types for each subexpression.  The 
base type, and the promoted type.  Calculations would use the promoted 
type as before; implicit narrowing conversions would be allowed down to 
the base type.

Subexpression           Base type       Promoted type
b                       byte            int
s1                      short           int
b + s1                  short           int
i                       int             int
b + i                   int             int
cast(short) (b + i)     short           int
s1 + cast(short) (b+i)  short           int
cast(int) (b + s1)      int             int

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 01 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
larry cowan wrote:

 In article <c1v7nk$to$1 digitaldaemon.com>, Stewart Gordon says...


<snip needless quoting>

 // the following would be illegal
 s1 = i;
 s1 = b + i;
 s1 = cast(int) (b + s1);


 
 Where does "s += i" fit?  What about "s += (f * d * r)"? Doesn't that
 look a bit out of line?


<snip needless quoting>

In the "Undefined identifier 's'" boat, according to my declarations. 
Otherwise, I suppose op= would be subject to the same legislation as = 
by itself.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 01 2004
parent reply larry cowan <larry_member pathlink.com> writes:
Ok, guess I misread your intentions for base level assign.
So "s + r" would have base r - falling into illegal.
Mar 01 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
larry cowan wrote:

 Ok, guess I misread your intentions for base level assign.
 So "s + r" would have base r


Correct.


 falling into illegal.


Illegal to do what with, exactly?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 02 2004
prev sibling next sibling parent reply Mark T <Mark_member pathlink.com> writes:
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


Comments?




require explict cast or someone will have to create a lint for D!
Feb 26 2004
next sibling parent reply Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Fri, 27 Feb 2004 03:23:10 +0000 (UTC) (02/27/04 14:23:10)
, Mark T <Mark_member pathlink.com> wrote:


 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


 Comments?




 require explict cast or someone will have to create a lint for D!


Can I trademark the name 'lindt' as the D Lint ;-) hmmmmm...chocolate...

-- 
Derek
Feb 26 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Derek Parnell" <Derek.Parnell Psyc.ward> wrote in message
news:opr30enbjydeu3pf news.digitalmars.com...

 On Fri, 27 Feb 2004 03:23:10 +0000 (UTC) (02/27/04 14:23:10)
 , Mark T <Mark_member pathlink.com> wrote:


 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


 Comments?




 require explict cast or someone will have to create a lint for D!


 Can I trademark the name 'lindt' as the D Lint ;-) hmmmmm...chocolate...


Lindt is the entry level "true" chocolate. Affordable, digestible, doesn't
leave one with a poor after taste/texture.

However, my favourite is Grand Cruz. Very yummy.

All that filth that all the English speaking countries call chocolate - milk
fats and vegetable fats; bleuch! - should be banned. Only the true stuff is
worth having. :)
Feb 26 2004
parent "Phill" <phill pacific.net.au> writes:
Ive never had Lindt or Grand Cruz(where do you get it?)

 I like Cadbury's Fruit & Nut.
Surely you cant resist that Mathew? I
think I could eat a square metre of it :o))

Phill.


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c1mk0r$800$1 digitaldaemon.com...

 "Derek Parnell" <Derek.Parnell Psyc.ward> wrote in message
 news:opr30enbjydeu3pf news.digitalmars.com...

 On Fri, 27 Feb 2004 03:23:10 +0000 (UTC) (02/27/04 14:23:10)
 , Mark T <Mark_member pathlink.com> wrote:


 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


 Comments?




 require explict cast or someone will have to create a lint for D!


 Can I trademark the name 'lindt' as the D Lint ;-) hmmmmm...chocolate...


 Lindt is the entry level "true" chocolate. Affordable, digestible, doesn't
 leave one with a poor after taste/texture.

 However, my favourite is Grand Cruz. Very yummy.

 All that filth that all the English speaking countries call chocolate -


milk

 fats and vegetable fats; bleuch! - should be banned. Only the true stuff


is

 worth having. :)
Feb 29 2004
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Mark T wrote:


 require explict cast or someone will have to create a lint for D!


I think that's not a bad idea at all! Splint is open and has a 
well-defined interface to adapt it to different languages, or so they 
say. Something like "splindid" is dancing on my tongue. :>

-eye
Feb 27 2004
parent reply Mark T <Mark_member pathlink.com> writes:
In article <c1o22q$2kbm$1 digitaldaemon.com>, Ilya Minkov says...

Mark T wrote:


 require explict cast or someone will have to create a lint for D!


I think that's not a bad idea at all! Splint is open and has a 
well-defined interface to adapt it to different languages, or so they 
say. Something like "splindid" is dancing on my tongue. :>


Why not fix some of the problems C has that forced lint-like tools to be created
in the first place?

Ada does not need a lint tool! You can do pointers, casting, etc but it must be
explicit in the code.

Too many things in C are dependent on the compiler writer's interpretation, this
is bad. Google "Les Hatton Safer C" if you want to learn more.
Feb 29 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Mark T wrote:


 Why not fix some of the problems C has that forced lint-like tools to be
created
 in the first place?


Because we need to avoid too much change as compared to C semantics.


 Ada does not need a lint tool! You can do pointers, casting, etc but it must be
 explicit in the code.


Ada is quite another kind of language. D would not be a C succesor any 
longer if it went that way. Not that i would be against it, but it 
doesn't seem possible, targetting wide audience.


 Too many things in C are dependent on the compiler writer's interpretation,
this
 is bad. Google "Les Hatton Safer C" if you want to learn more.


I can't find anything concrete, just general descriptions of this work 
in a few lines. In my point of view, C forces everyone to learn to 
program sanely by himself by providing a painfull experience, but does 
not offer really help with it.

And recall that Walter is against warnings. With that, we are inevitably 
incorporating some safety in the compiler on the one hand, but also 
offloading the rest onto a separate tool.

-eye
Mar 01 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ilya Minkov wrote:


 Mark T wrote:
 

 Why not fix some of the problems C has that forced lint-like tools to 
 be created in the first place?




It does.  Near the end of the overview:

"D compilers will not generate warnings for questionable code. Code will 
either be acceptable to the compiler or it will not be. This will 
eliminate any debate about which warnings are valid errors and which are 
not, and any debate about what to do with them. The need for compiler 
warnings is symptomatic of poor language design."

And as I said before,
"If you're going to stay true to your 'no warnings' philosophy, you 
should make them errors, rather than getting rid of them altogether."


 Because we need to avoid too much change as compared to C semantics.


According to the FAQ, the point is "to make code that looks the same as 
in C operate the same. If it had subtly different semantics, it will 
cause frustratingly subtle bugs."

Several things in C are already illegal in D.  A compiler error would 
not constitute a "frustratingly subtle bug".  Quite the opposite, it 
would force the programmer to fix what would otherwise lead to a 
frustratingly subtle bug in itself.

<snip>

 Ada is quite another kind of language. D would not be a C succesor any 
 longer if it went that way. Not that i would be against it, but it 
 doesn't seem possible, targetting wide audience.


<snip>

Define "C successor".  You're not thinking of the word "superset", are you?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 02 2004
parent reply Mark T <Mark_member pathlink.com> writes:
 Because we need to avoid too much change as compared to C semantics.


According to the FAQ, the point is "to make code that looks the same as 
in C operate the same. If it had subtly different semantics, it will 
cause frustratingly subtle bugs."

Several things in C are already illegal in D.  A compiler error would 
not constitute a "frustratingly subtle bug".  Quite the opposite, it 
would force the programmer to fix what would otherwise lead to a 
frustratingly subtle bug in itself.


totally agree - why bring forward the stuff in C that is pretty much wrong
except for operator precedence which has known problems, but would confuse
people if changed

besides I thought Walter originally wanted C-style syntax not necessarily all
the semantics (i.e. baggage) otherwise let's just use C++


correct some C-isms?

One fix I can think of:

if ( boolean_expression ) 
in Java boolean_expression can't be an "int" it has to be a Boolean variable or
expression
Mar 03 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Mark T wrote:

<snip>

 totally agree - why bring forward the stuff in C that is pretty much wrong
 except for operator precedence which has known problems, but would confuse
 people if changed
 
 besides I thought Walter originally wanted C-style syntax not necessarily all
 the semantics (i.e. baggage) otherwise let's just use C++


Totally agree.  I particularly think carrying forward the switch 
fall-through was silly.  Like, no frustratingly subtle bug can possibly 
arise from requiring that the point immediately between a statement and 
a case label be either unreachable, or marked explicitly as a 
fallthrough by some means.  Or by having discarded it in favour of 
something more structured (like what I proposed a while back) in the 
first place.

After all, if we really are trying to stop subtle bugs by people used to 
C, why the exception on no matching case or default?



 correct some C-isms?
 
 One fix I can think of:
 
 if ( boolean_expression ) 
 in Java boolean_expression can't be an "int" it has to be a Boolean variable or
 expression 


Java also made some warnings errors, like:
- Possible use of 'qwert' before assignment
- Code has no effect (at least in the most basic instances)

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Mar 04 2004
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Mark T wrote:


 require explict cast or someone will have to create a lint for D!


Every successfull tool, that accompanies D, can be integrated into the
language in the next version.

The prophecy of the future existence of such tools yields the usefullness
of the language as it currently is.

So long.
Feb 27 2004
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Walter wrote:


 At issue is whether implicit narrowing conversions should be allowed


[...]

Implicit or explicit does not matter when the term "narrowing
conversion" stays undefined, because no competing compiler will be able to
mimic the unknown behaviour of dmd.

So long!
Mar 21 2004