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.

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

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.

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.

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/

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

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

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/

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.

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/