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 > > to: > > > > byte b2 = b; > > b2 += b; > > > > We don't want adding 2 bytes together to result in a byte result in all > > cases, > > only in cases where the actual assignment or usage is to a byte. > > Well the "most" part doesn't quite pan out, and to me it looks like the > argument fails here. For one thing, we need to eliminate people who accept > Java > and C#. They would believe that what their language does is the better thing > to > do. Just because people use a language, doesn't mean they agree with every decision. In searching for this issue on C# blogs and message boards, the overwhelming majority prefers no error to the oversafe current implementation. The defenders of the current rules invariably use the case of adding two bytes together and assigning to an integer, their argument being that if you have the result of adding two bytes be a byte, then the integer result is a truncated byte. If we eliminate that case from contention, as my solution has done, I think you'd be hard pressed to find anyone who thinks the loss of data errors are still needed in the cases such as the one that spawned this discussion. > Also, C and C++ are getting that right by paying a very large cost - of > allowing all narrowing integral conversions. I believe there is a reasonable > level of agreement that automatic lossy conversions are not to be encouraged. > This puts C and C++ behind Java and C# in terms of "getting it right". I agree, general narrowing conversions should be failed. It's just in the case of where arithmetic has artificially promoted the result where we disagree. > > > What if we defined several 'internal' types that were only used by the > > compiler? > > > > pbyte -> byte promoted to an int (represented as an int internally) > > pubyte -> ubyte promoted to an int > > pshort -> short promoted to an int > > pushort -> ushort promoted to an int > > etc... > > IMHO not enough rationale has been brought forth on why this *should* be > implemented. It would make D implement an arcane set of rules for an odd, if > any, benefit. Probably, it isn't that critical to the success of D that this be implemented. If I had to choose something to look at, this probably wouldn't be it. This is just one of those little things that seems unnecessary and annoying more than it is blocking. It shows up seldom enough that it probably isn't worth the trouble to fix. But I have put my solution forth, and as far as I can tell, you didn't find anything wrong with it, and that's about all I can do. > 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 reasonable solution. > For > now, D has borrowed the C rule "if any operand is unsigned then the result is > unsigned" leading to the occasional puzzling results known from C and C++. > Eliminating those fringe cases without losing compatibility with C and C++ is > a > tough challenge. Indeed. Without promoting to a larger type, I think you are forced to take this course of action. When adding an int to a uint, who wants it to wrap around to a negative value? I can't think of a better solution. --
