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

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/

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

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.

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

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.

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.

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.

Ok, guess I misread your intentions for base level assign. So "s + r" would have base r - falling into illegal.

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