http://d.puremagic.com/issues/show_bug.cgi?id=1977
Jason House changed:
What|Removed |Added
CC||jason.james.ho...@gmail.com
--- Commen
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #19 from [EMAIL PROTECTED] 2008-11-25 09:17 ---
(In reply to comment #18)
> > A better problem to spend energy on is the signed <-> unsigned morass. We've
> > discussed that many times and could not come up with a reasonab
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #18 from [EMAIL PROTECTED] 2008-11-25 09:02 ---
(In reply to comment #17)
> > And most believe that:
> >
> > byte b2 = b + b;
> >
> > should produce b2 == -128 without error, and should be equivalent
> > semantically
>
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #17 from [EMAIL PROTECTED] 2008-11-24 18:51 ---
(In reply to comment #16)
> I searched around, and you are right that C# disallows compiling byte + byte
> operands, and it does allow += operands. The reasons given were no
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #16 from [EMAIL PROTECTED] 2008-11-24 16:55 ---
I searched around, and you are right that C# disallows compiling byte + byte
operands, and it does allow += operands. The reasons given were not to forbid
reassignment to th
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #15 from [EMAIL PROTECTED] 2008-11-24 14:48 ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > (In reply to comment #10)
> > > > c += 'A' - 'a';
> > > >
> > > > Casting seems too
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #14 from [EMAIL PROTECTED] 2008-11-24 14:47 ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #10)
> > > c += 'A' - 'a';
> > >
> > > Casting seems too strict a requirement in these types o
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #13 from [EMAIL PROTECTED] 2008-11-24 13:41 ---
(In reply to comment #12)
> (In reply to comment #10)
> > c += 'A' - 'a';
> >
> > Casting seems too strict a requirement in these types of situations. I
> > can't
> > imag
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #12 from [EMAIL PROTECTED] 2008-11-22 13:22 ---
(In reply to comment #10)
> (In reply to comment #7)
> > In general, we want to go with the simple rule is to have an operation
> > return
> > the tightest type that won't e
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #11 from [EMAIL PROTECTED] 2008-11-22 12:51 ---
(In reply to comment #9)
> (In reply to comment #8)
> > The plan is to have sensible bitwise operations preserve the size of their
> > operands. Only arithmetic and shift wil
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #10 from [EMAIL PROTECTED] 2008-11-22 12:39 ---
(In reply to comment #7)
> In general, we want to go with the simple rule is to have an operation return
> the tightest type that won't engender overflow (which precludes mak
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #9 from [EMAIL PROTECTED] 2008-11-22 11:22 ---
(In reply to comment #8)
> The plan is to have sensible bitwise operations preserve the size of their
> operands. Only arithmetic and shift will "spill" into larger types.
>
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #8 from [EMAIL PROTECTED] 2008-11-22 11:04 ---
(In reply to comment #6)
> (In reply to comment #4)
> > It's not ridiculous at all. The compiler cannot tell what values
> > will be possibly passed to f, and the range of b
http://d.puremagic.com/issues/show_bug.cgi?id=1977
--- Comment #7 from [EMAIL PROTECTED] 2008-11-22 10:59 ---
(In reply to comment #5)
> (In reply to comment #4)
> > It's not ridiculous at all. The compiler cannot tell what values will be
> > possibly passed to f, and the range of byt
http://d.puremagic.com/issues/show_bug.cgi?id=1977
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|normal |enhancement
Summary|integ
15 matches
Mail list logo
