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

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

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!

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

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/

"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. :)

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.

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

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.

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/