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,

     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

 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?
 
 

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,


     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


 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=

 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=


 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=

 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


 because the compiler will do whatever it takes to satisfy the cast.


 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


 say get rid of the integral promotion rules, but then D will have a


 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


 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,


     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


 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

 because the compiler will do whatever it takes to satisfy the cast.

 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. 

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. 

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.
  

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.

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,

     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

 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. 

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.

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?

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

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

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 -

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

 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.

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++ Since Java and C# are now popular C-style syntax languages, what did they do to 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?
 Since Java and C# are now popular C-style syntax languages, what did they do to
 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