Joe and Andi,
I agree that long long is probably questionable right now. Something that seems debatable to me is: should we ever promote an integer type to a floating type, simply on value? I guess it would make sense to enumerate the schools of thought on this and the corresponding cast to a smaller type...
1) integer promotion to double enhances usability by extending the range of effective integers rather dramatically and largely transparently, so it should remain.
2) integer promotion to double introduces questions of behavior and consistency, and should likewise be removed
A) the integer-typed value of a large number should represent the largest value an integer may hold, sharing the same sign
B) the integer-typed value of a large number should represent the bitwise portion of the large value that the integer type may hold
B.1) the sign bit in the integer should be set to zero, since the corresponding bit in the large value represents something out of range of the type
B.2) the sign bit in the integer should be set to the sign bit of the larger value, after filling the remaining lowest bits
B.3) the sign bit should be effectively ignored, and the full bit capacity of the integer should be filled from the larger value, throwing a warning, regardless of values.
C) since PHP knows the values and ranges of types at runtime, it should throw a (possibly fatal) catchable error when an overflow would occur, since the result is of questionable significance, regardless of the bitwise behavior
--
I think I would say that promoting integer constants to double implicitly hurts semantics a bit. To use integer constants AS a double, they should be cast explicitly, otherwise defaulting to the integer behavior.
When possibly overflowing an integer beyond the signed positive upper bound, through math operations or assignment (from constant or larger type), it should behave like a native integer. That is, giving a warning about value range for known dangerous operations, and setting the sign bit obliviously. I think it would stand to add ``magic bugs'' if warnings were only issued on runtime assignments that would be dangerous. Maybe a dynamic_cast<>-style operation would be desired.
In short, I think the previous behavior is somewhat less surprising, but we need to make sure a change from now addresses all the concerns we have.
Where does anyone stand on this? Have I left out any compelling ideas?
Thanks, -Noah
Andi Gutmans wrote: > So basically you're saying that we should return to previous behavior, > right?
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
