Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
October 28, 2010 byte & byte | ||||
---|---|---|---|---|
| ||||
can someone remind why the resulting type is int? is it a "c does it" thing? |
October 28, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ellery Newcomer | 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
|
October 28, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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
|
October 28, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ellery Newcomer | 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
|
October 28, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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
|
October 28, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ellery Newcomer | 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?
|
October 28, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | 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?
|
October 29, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ellery Newcomer | 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.
|
October 29, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | 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); } |
October 29, 2010 Re: byte & byte | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ellery Newcomer | 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. |
Copyright © 1999-2021 by the D Language Foundation