View mode: basic / threaded / horizontal-split · Log in · Help
February 28, 2004
Re: Implicit narrowing conversions
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
February 28, 2004
Re: Implicit narrowing conversions
Robert M. Münch wrote:

> On Sat, 28 Feb 2004 22:36:19 +0800, J Anderson  
> <REMOVEanderson@badmama.com.au> wrote:
>
>> If this was implemented, should explicit narrow casting still be 
>> allowed  also?
>> My guess is that explicit narrow casting will still be nessary and 
>> it  would be a matter of advocating *narrow* as best practice.
>
>
> Hi, sorry I don't get it. What I suggested is explict narrow casting 
> with  an implicit implementation. It's not stating anything about what 
> to do,  only that it's OK. It's like an enabler for the compiler to do 
> what it  does at the moment but with explict OK from the programmer. 
> The only  purpose it to be sure that the downsizing isn't by accident.
>
> Or did you meant something different?
>
Nar, I understand that. What I mean is:

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

But we will probably still need explicit narrow casting:

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

So both:

  c = (char) i;  

     c = narrow(i);

would be valid.

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

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

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

-- 
-Anderson: http://badmama.com.au/~anderson/
February 29, 2004
Re: Implicit narrowing conversions
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
February 29, 2004
Re: Implicit narrowing conversions
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.
March 01, 2004
Re: Implicit narrowing conversions
Ive never had Lindt or Grand Cruz(where do you get it?)

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

Phill.


"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
news:c1mk0r$800$1@digitaldaemon.com...
>
> "Derek Parnell" <Derek.Parnell@Psyc.ward> wrote in message
> news:opr30enbjydeu3pf@news.digitalmars.com...
> > On Fri, 27 Feb 2004 03:23:10 +0000 (UTC) (02/27/04 14:23:10)
> > , Mark T <Mark_member@pathlink.com> wrote:
> >
> > > In article <c1iqf1$2oqg$1@digitaldaemon.com>, Walter says...
> > >>
> > >> At issue is whether implicit narrowing conversions should be allowed,
> > >> i.e.:
> > >>
> > >>    char c;
> > >>    int i;
> > >>    c = i;        // i implicitly 'narrowed' to char
> > >>
> > >>> Comments?
> > >
> > > require explict cast or someone will have to create a lint for D!
> > >
> > >
> >
> > Can I trademark the name 'lindt' as the D Lint ;-) hmmmmm...chocolate...
>
> Lindt is the entry level "true" chocolate. Affordable, digestible, doesn't
> leave one with a poor after taste/texture.
>
> However, my favourite is Grand Cruz. Very yummy.
>
> All that filth that all the English speaking countries call chocolate -
milk
> fats and vegetable fats; bleuch! - should be banned. Only the true stuff
is
> worth having. :)
>
>
March 01, 2004
Re: Implicit narrowing conversions
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.
March 01, 2004
Re: Implicit narrowing conversions
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.
March 01, 2004
Re: Implicit narrowing conversions
larry cowan wrote:
> In article <c1v7nk$to$1@digitaldaemon.com>, Stewart Gordon says...
<snip needless quoting>
>> // the following would be illegal
>> s1 = i;
>> s1 = b + i;
>> s1 = cast(int) (b + s1);
> 
> Where does "s += i" fit?  What about "s += (f * d * r)"? Doesn't that
> look a bit out of line?
<snip needless quoting>

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

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
March 01, 2004
Re: Implicit narrowing conversions
Ok, guess I misread your intentions for base level assign.
So "s + r" would have base r - falling into illegal.
March 01, 2004
Re: Implicit narrowing conversions
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
2 3 4 5 6 7
Top | Discussion index | About this forum | D home