function main() {
final a = 0;
final b = 1;
Sys.println(a & b);
return;
}
This generates:
local a = 0
local b = 1
_G.print(Std.string(_hx_bit.band(a,b)))
Here _hx_bit.band(a,b) has to perform int 32 clamping which adds overhead and means it cannot work with 64 bit operations which some lua implementations support. Int is defined as platform dependent, so it would be better to be closer to the native operations without the extra clamping. For example, for lua 5.3+ we could also instead generate an inline native operator for more readable output.
We should keep the clamping behaviour for haxe.Int32 and haxe.Int64, but not have it for Int.
Similarly, Std.int() clamps to 32 bit, but some lua implementations have 64 bit integers so we should be less strict here. (Lua 5.3 should also make use of math.tointeger)
Related to #8095. Some tests specify 32 bit behaviour for Int for only certain operators, but it seems better to keep that for Int32.
This generates:
Here
_hx_bit.band(a,b)has to perform int 32 clamping which adds overhead and means it cannot work with 64 bit operations which some lua implementations support. Int is defined as platform dependent, so it would be better to be closer to the native operations without the extra clamping. For example, for lua 5.3+ we could also instead generate an inline native operator for more readable output.We should keep the clamping behaviour for
haxe.Int32andhaxe.Int64, but not have it forInt.Similarly,
Std.int()clamps to 32 bit, but some lua implementations have 64 bit integers so we should be less strict here. (Lua 5.3 should also make use of math.tointeger)Related to #8095. Some tests specify 32 bit behaviour for Int for only certain operators, but it seems better to keep that for Int32.