can someone remind why the resulting type is int?

is it a "c does it" thing?

On Wed, 27 Oct 2010 22:49:47 -0400, Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:

> can someone remind why the resulting type is int?
>
> is it a "c does it" thing?

Yes, but it should be reassignable to a byte via range propogation.  With C, there was no range propogation, so int & int was also assignable to char.

-Steve

Hm. Thanks for the heads up.

Now how about

byte &= int

is there any good reason why the result type of that isn't error?

On 10/27/2010 10:12 PM, Steven Schveighoffer wrote:
> On Wed, 27 Oct 2010 22:49:47 -0400, Ellery Newcomer
> <ellery-newcomer@utulsa.edu> wrote:
>
>> can someone remind why the resulting type is int?
>>
>> is it a "c does it" thing?
>
> Yes, but it should be reassignable to a byte via range propogation. With
> C, there was no range propogation, so int & int was also assignable to
> char.
>
> -Steve

On Wed, 27 Oct 2010 23:34:04 -0400, Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:

> Hm. Thanks for the heads up.
>
> Now how about
>
> byte &= int
>
> is there any good reason why the result type of that isn't error?

Well, if 'int' represents a literal, or a manifest constant, they are not exactly ints.  When the compiler can tell that the result of the operation will fit into a byte, it allows it to go through.  I believe when it can't tell, it should error, but &= may be a special case, I'm not sure.

-Steve

Next question:

why does

(~ short) result in short, but in c it results in int?

On 10/27/2010 11:02 PM, Steven Schveighoffer wrote:
>
> Well, if 'int' represents a literal, or a manifest constant, they are
> not exactly ints. When the compiler can tell that the result of the
> operation will fit into a byte, it allows it to go through. I believe
> when it can't tell, it should error, but &= may be a special case, I'm
> not sure.
>
> -Steve

Ellery Newcomer Wrote:

> Next question:
> 
> why does
> 
> (~ short) result in short, but in c it results in int?

I see no reason for this or byte & byte to return an int. Since this would only cause C code to not compile, why not change it?

erm, wut?

On 10/28/2010 12:56 PM, Jesse Phillips wrote:
>
> I see no reason for this or byte&  byte to return an int. Since this would only cause C code to not compile, why not change it?

Ellery Newcomer Wrote:

> erm, wut?
> 
> On 10/28/2010 12:56 PM, Jesse Phillips wrote:
> >
> > I see no reason for this or byte&  byte to return an int. Since this would only cause C code to not compile, why not change it?

This should compile:

void main() {
   byte a = 5;
   byte b = 10;
   short c = 9;

   auto i = 5 & 10;
   auto j = ~c

   assert(typeof(i) == typeid(byte));
   assert(typeof(j) == typeid(short));
}

Because C code will not behave differently and since it is a smaller type it can only cause C code not to compile. And in reality it the change should only effect D code that uses type inference, but will not result in any broken code since byte is implicitly an int.

On 10/29/2010 10:48 AM, Jesse Phillips wrote:
> Because C code will not behave differently
>

I'm not convinced of this. Proposed counterexample:

// test.d
import std.stdio;
void main(){
  ushort x = 0xffff;
  writefln("%08x", ~x+1u);
}


// test.c
#include <stdio.h>
void main(void){
  unsigned short x = 0xffff;
  printf("%08x", ~x+1u);
}

Ellery Newcomer Wrote:

> On 10/29/2010 10:48 AM, Jesse Phillips wrote:
> > Because C code will not behave differently
> >
> 
> I'm not convinced of this. Proposed counterexample:
> 
> // test.d
> import std.stdio;
> void main(){
>    ushort x = 0xffff;
>    writefln("%08x", ~x+1u);
> }

http://ideone.com/OsbTE

> // test.c
> #include <stdio.h>
> void main(void){
>    unsigned short x = 0xffff;
>    printf("%08x", ~x+1u);
> }

http://ideone.com/4S4QO

Ok, truly not what I was thinking would happen. I believe D's behavior to be correct, but as it is the exact same code I think it is worthy of a bug report.