Thanks Everybody for responding. I have another query which is off-topic but related.

Why is the following allowed in D?

long a;
int b;

b += a; // Allowed -- no explicit cast
b = a + b; // Not allowed
b = a;      // Not allowed

d coder:

> Why is the following allowed in D?
>
> long a;
> int b;
>
> b += a; // Allowed -- no explicit cast
> b = a + b; // Not allowed
> b = a;      // Not allowed

Seems a bug of range analysis.

Bye,
bearophile

On 12/11/12 11:36 AM, d coder wrote:
> Thanks Everybody for responding. I have another query which is off-topic
> but related.
>
> Why is the following allowed in D?
>
> long a;
> int b;
>
> b += a; // Allowed -- no explicit cast

RMW operations are allowed without a cast.

Andrei

On 12/11/2012 5:24 AM, d coder wrote:
> Would I be asking for too much if I ask DMD to provide a compiler
> flag that makes it return bytes and shorts for operations on them? So the deal
> would be, if you use this compiler flag, code behavior would be different from
> that of C/C++.

Having compiler flags that fundamentally change the behavior of the language are a disaster from about every point of view.

On Tue, 11 Dec 2012 09:47:33 -0800
Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/11/2012 5:24 AM, d coder wrote:
> > Would I be asking for too much if I ask DMD to provide a compiler flag that makes it return bytes and shorts for operations on them? So the deal would be, if you use this compiler flag, code behavior would be different from that of C/C++.
> 
> Having compiler flags that fundamentally change the behavior of the language are a disaster from about every point of view.
> 

Yea, I'd hate to see D turn into PHP. That's one of the biggest
reasons I despise PHP - code can't rely on fucking *anything* in it to
ever work in any particular way. Pick any random line of PHP code,
and there's about 20 different things it might do, even on the exact
same version of PHP, all depending on a billion different configuration
settings. Any library written in PHP is *inherently* broken simply by
being one codebase intending to be "usable" on different servers.

Let's not entertain any thoughts of allowing D to venture down that path.

On Tuesday, 11 December 2012 at 16:09:14 UTC, Andrei Alexandrescu wrote:
> On 12/11/12 8:24 AM, d coder wrote:
>>
>>    No, it's a fix of a gotcha from C. The C code would just allow the
>>    assignment.
>>
>>
>> Yes Andrei.
>>
>> But it does not look clean if you have to write:
>>
>> byte a, b, c;
>> a = cast(byte) (b + c);
>>
>> Well I know the advantages (safety). But imagine having to write all
>> that when working with bytes and shorts. Makes it really difficult to
>> work with shorts and bytes in D.
>
> Value range propagation automatically avoids the need for a lot of those casts. http://www.drdobbs.com/tools/value-range-propagation/229300211
>
>> Would I be asking for too much if I ask
>> DMD to provide a compiler flag that makes it return bytes and shorts for
>> operations on them?
>
> That won't happen.
>
>
> Andrei

But than we have a bug in the value range propagation algorithm.
E.g in the original program:
void main()
{
 import std.stdio;
 ushort a = 0x55AA;
 ushort b = 0xAA55;
 writefln("%X", ~(a | b));
}

(a | b) will be in the range of ushort values and ~ of that also remains in the same value range. In other words, it makes no sense that boolean ops (and, or, xor, 1's compliment, 2's compliment) will require type promotion as they cannot exceed the original width of the values. This is unlike arithmetic which can require promotion.

On 12/11/2012 10:12 AM, Nick Sabalausky wrote:
> Let's not entertain any thoughts of allowing D to venture down that
> path.

No worries there :-) I feel pretty dang strongly about this issue, from bad experience.

Even if a language behaves "wrong", it is still usable if it is predictable.

On Tuesday, 11 December 2012 at 14:02:52 UTC, d coder wrote:
> On Tue, Dec 11, 2012 at 7:05 PM, Peter Alexander <
> peter.alexander.au@gmail.com> wrote:
>
>> That's the whole point. What you are doing is dangerous, so it requires
>> the cast.
>>
>
>
> What I am doing is not dangerous. I am operating at byte/short level.
> Tell me, if what I am doing is dangerous, how come doing the following is
> not dangerous. It is allowed by D.
>
> int a, b, c;
> a = b + c;
>
> Also the sense of safety that you get for short and byte too is not
> complete. Consider:
>
> void main() {
>   import std.stdio;
>   ushort a = ushort.max;
>   ushort b = ushort.max;
>   a += b;
>   writeln(a);
> }
>
>
> Is it too much to ask for consistent behavior across the built-in types?
>
> Regards
> - Puneet

What if you create a new type that creates the proper functionality and does the implicit casting and such? This would hide away the details but maybe at a cost of efficiency.

e.g.,

struct bbyte {
byte value;
...
}

bbyte a; bbyte b;

b = a + b; // uses bbyte's operators and casts to do the computation and assignment but then returns a bbyte instead of an int.

You should have no problems implicitly converting bbyte to built in types or built in types to bbyte.

On Wed, Dec 12, 2012 at 3:40 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> No worries there :-) I feel pretty dang strongly about this issue, from bad experience.
>
> Even if a language behaves "wrong", it is still usable if it is predictable.
>

Agreed.

How about this.

1. Let "char" and "short" behave the C/C++ way. These can return integers.
This will make C/C++ code work in D.
2. Make D "byte" operations return bytes. And create another type (named
say dbyte or shortint) and make operations on the new type return
shortints. This will make these types more usable in D code. Well we end up
adding another keyword, but we shall get workable and safe 8-bit and 16-bit
integrals.

Regards
- Puneet

On Wednesday, 12 December 2012 at 03:10:15 UTC, d coder wrote:
> On Wed, Dec 12, 2012 at 3:40 AM, Walter Bright
> <newshound2@digitalmars.com>wrote:
>
>> No worries there :-) I feel pretty dang strongly about this issue, from
>> bad experience.
>>
>> Even if a language behaves "wrong", it is still usable if it is
>> predictable.
>>
>
> Agreed.
>
> How about this.
>
> 1. Let "char" and "short" behave the C/C++ way. These can return integers.
> This will make C/C++ code work in D.
> 2. Make D "byte" operations return bytes. And create another type (named
> say dbyte or shortint) and make operations on the new type return
> shortints. This will make these types more usable in D code. Well we end up
> adding another keyword, but we shall get workable and safe 8-bit and 16-bit
> integrals.
>
> Regards
> - Puneet

What's now is safer than what you propose. You can always create your own data type that would automatically truncate result if you wish so.