February 26, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Burton Radons | 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.
>
|
February 26, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | 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.
>
|
February 27, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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! |
February 27, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mark T | 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 |
February 27, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to J Anderson | 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/ |
February 27, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | "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. :) |
February 27, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ilya Minkov | 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.
|
February 27, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mark T | 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
|
February 27, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mark T | 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.
|
February 28, 2004 Re: Implicit narrowing conversions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert M. Münch | 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/ |
Copyright © 1999-2021 by the D Language Foundation