From 53b04f06567dfafac99cb02f562421b8e8eb43a2 Mon Sep 17 00:00:00 2001 From: flashultra Date: Fri, 6 Jan 2023 21:55:29 +0200 Subject: [PATCH 1/7] Int64 data type --- proposals/0000-integer-data-types.md | 60 ++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 proposals/0000-integer-data-types.md diff --git a/proposals/0000-integer-data-types.md b/proposals/0000-integer-data-types.md new file mode 100644 index 0000000..c228074 --- /dev/null +++ b/proposals/0000-integer-data-types.md @@ -0,0 +1,60 @@ +# Integer data types + +* Proposal: [HXP-NNNN](NNNN-filename.md) +* Author: [MJ](https://github.com/flashultra) + +## Introduction + +Allowing easy assignment of Int64 type for all Haxe targets. Replacing with native Int64 , where is it possible and use abstract for others. + +## Motivation + +Before Int64 literal suffix, it was more inconvenient to use Int64 (by calling Int64.make() ) and to create Int64 constant. +Still, sometimes is less readable when for example have this +```haxe + var x = 2147483i64; // this is 2147483 ( Int64) + var y = 2147483164; // this is 2147483164 ( Int32) +``` +Using a number separator makes things better, but still be better to use ```var y:Int64 = 4294967296;``` vs ```var y:Int64 = 4294967296_i64;``` as we know the type of the variable. + +## Detailed design + +Many of the Haxe targets supports Int64 type ( long, long long int , Int64 ) , so where is possible the Int64 abstract class should be replaced with the native for the target, and this should give better performance too. +This will match Haxe with many other languages where assignment on integer values is possible without calling function ( Int64.make) + Also, it will be possible to use implicitly typed variables using this order against the value : ```Int < UInt < Int64 < UInt64```. +For example: +```haxe + var x = 2147483647; // Int + var y = 4294967295; // UInt + var v = 9223372036854775807; // Int64 + var w = 18446744073709551615; // UInt64 +``` +The new UInt64 type should be available for all targets ( at the moment, it is introduced in cs,cpp,eval). +Of course, the following assignment should be possible too: +```haxe + var x:Int = 2147483647; + var y:UInt = 4294967295; + var v:Int64 = 9223372036854775807; + var w:UInt64 = 18446744073709551615; +``` +The other thing is Int and Int32. For some target Int could be a float ( javascript, for example), so not having a consistent overflow could lead to strange results and expectations. Not sure how many use Int and unexpected recieve Int64 value after that. Maybe it will be good to unify those two classes, but not sure how this could affect performance ( for javascript , php , python, Lua) +For example ``` var b:Int = 2147483647 * 349342;``` will give 750206232210274 in JS ( 0x2AA4EFFFAAB62) + +## Impact on existing code + +None + +## Drawbacks + +The problem will be with the implicitly vars if the user think assigment of the 4294967295 will lead to Int64, not UInt, so maybe the type should be mandatory for values above 2147483647 ? + +## Alternatives + +Alternatives will be using Int64 literal suffix and number separator + +## Opening possibilities + + +## Unresolved questions + + From ff44756985d1b9faf49082cbf24132671dd0a15d Mon Sep 17 00:00:00 2001 From: flashultra Date: Thu, 26 Jan 2023 11:37:57 +0200 Subject: [PATCH 2/7] Add description for conversion between types, UInt64 type --- proposals/0000-integer-data-types.md | 96 ++++++++++++++++++++++++++-- 1 file changed, 89 insertions(+), 7 deletions(-) diff --git a/proposals/0000-integer-data-types.md b/proposals/0000-integer-data-types.md index c228074..0bc456b 100644 --- a/proposals/0000-integer-data-types.md +++ b/proposals/0000-integer-data-types.md @@ -1,3 +1,4 @@ + # Integer data types * Proposal: [HXP-NNNN](NNNN-filename.md) @@ -5,10 +6,30 @@ ## Introduction -Allowing easy assignment of Int64 type for all Haxe targets. Replacing with native Int64 , where is it possible and use abstract for others. +The current proposal have four goals: +- Replacing Int64 , UInt and UInt64 with native types (where is possible) . +- Allowing easy assignment for Int64 ,UInt and UInt64 +- Introduce new type UInt64 for all Haxe targets and use native, where is possible. +- Allowing easy conversion between integer data types. + ## Motivation +### Replacing Int64 , UInt and UInt64 with native types +Some of the Haxe targets support integer types natively. + - C/C++ - - int64_t, uint32_t, uint64_t; + - Java - long ; + - C# - long, uint, ulong + + Using native type for above targets which allowed could give better performance. + + For other targets: + - Pyton - numbers have unlimited size. + - JS - could be use abstraction over BigInt ( for Int64 and UInt64) as it have better performance. + - Php - by default integer is 64-bit ( for 64-bit systems) and 32-bits ( for 32-bit system). Haxe could emulate 64-bit (over 32-bit systems) and use default Int for others. + - Lua (>=5.3) - support 64-bit integer types + +### Allowing easy assignment for Int64 ,UInt and UInt64 Before Int64 literal suffix, it was more inconvenient to use Int64 (by calling Int64.make() ) and to create Int64 constant. Still, sometimes is less readable when for example have this ```haxe @@ -16,18 +37,66 @@ Still, sometimes is less readable when for example have this var y = 2147483164; // this is 2147483164 ( Int32) ``` Using a number separator makes things better, but still be better to use ```var y:Int64 = 4294967296;``` vs ```var y:Int64 = 4294967296_i64;``` as we know the type of the variable. + At the current moment it's not possible to assign value with decimal representation above 0x7FFFFFFF ( 2147483647) for UInt + For example, the following assigment is invalid ``` var m:UInt = 3147483647;``` which is incovinient. + For UInt64 should be allowed to assign above 9223372036854775807 ( 0x7FFFFFFFFFFFFFFF) in the code. + +### Introduce new type UInt64 +At the moment UInt64 is introduced in C#, C++ and Eval. Should be presented in all Haxe target as emulation or as native type ( if possible) + +### Allowing easy conversion between integer data types. +The current solution with the suffix give soltion for the problems like this +```haxe +var mask:Int64 = 1i64 << 32; +``` +but not for the problem like this: +```haxe + var one:Int = 1; + var mask:Int64 = one << 32; +``` +The following code could be rewrite like this +```haxe + var one:Int = 1; + var mask:Int64 = Int64.make(0,one) << 32 +``` +or like +```haxe + var one:Int = 1; + var mask = Int64.shl(one,32); +``` +Still this won't give a solution for the problem of multiplying UInt +```haxe + var m:UInt = 0xBB9AC9FF; + var n:UInt = 0xEC7A87C6; + var mask:Int64 = m*n; + //or + var mask:Int64 = Int64.mul(m,n); +``` +For different targets, give dfferent result, but never correct one ```-5959250239385521094``` +So if I want to multiply two UInt ( or Int) and want to receive as result Int64 is impossible in Haxe (or miss something?) . +One solution will be to add prefix before operand for the expected type ( similiar as c/c++/java/c#) which will allow and easy implementation for those targets. +Example : +```haxe + var m:UInt = 0xBB9AC9FF; + var n:UInt = 0xEC7A87C6; + var mask:Int64 = (i64)m*n; + //or + var mask:Int64 = (i64)m*(i64)n; + var mask:Int64 = m*(i64)n; +``` + ## Detailed design Many of the Haxe targets supports Int64 type ( long, long long int , Int64 ) , so where is possible the Int64 abstract class should be replaced with the native for the target, and this should give better performance too. This will match Haxe with many other languages where assignment on integer values is possible without calling function ( Int64.make) - Also, it will be possible to use implicitly typed variables using this order against the value : ```Int < UInt < Int64 < UInt64```. + Also, it will be possible to use implicitly typed variables using this order against the value : ~~Int < UInt < Int64 < UInt64~~ ```Int < Int64 < BigInt``` For example: ```haxe var x = 2147483647; // Int - var y = 4294967295; // UInt + var y = 4294967295; // Int64 //~~UInt var v = 9223372036854775807; // Int64 - var w = 18446744073709551615; // UInt64 + var w = 18446744073709551615; // BigInt //~~UInt64 ``` The new UInt64 type should be available for all targets ( at the moment, it is introduced in cs,cpp,eval). Of course, the following assignment should be possible too: @@ -40,13 +109,28 @@ Of course, the following assignment should be possible too: The other thing is Int and Int32. For some target Int could be a float ( javascript, for example), so not having a consistent overflow could lead to strange results and expectations. Not sure how many use Int and unexpected recieve Int64 value after that. Maybe it will be good to unify those two classes, but not sure how this could affect performance ( for javascript , php , python, Lua) For example ``` var b:Int = 2147483647 * 349342;``` will give 750206232210274 in JS ( 0x2AA4EFFFAAB62) +Easy conversion between different integer types could be implemented with adding preffix before the operand which will convert one int type to another. +For example : i64, u32, ui64 ; ```(i64)mask;```, ```(i32)mask;``` +Using only numbers (at the end) in the suffix and the prefix could lead to less readable code , so it could be added other alphabet such as: i64_t, u32_t, ui64_t ; ```(i64_t)mask;```, ```(u32_t)mask;``` + +Other question is how to convert UInt var to Int64 +For example if have: +```haxe + var m:UInt = 0xBB9AC9FF; + var mask:Int64 = Int64.make(0x0,m); //didn't work +``` +So we want to keep Int64.high to 0x0 and assign the UInt var only the the low part. +It's not possible in Haxe at the moment. So something like this could be allow: +``` var mask:Int64 = (m & (i64_t)0xFFFFFFFF);``` + ## Impact on existing code None ## Drawbacks -The problem will be with the implicitly vars if the user think assigment of the 4294967295 will lead to Int64, not UInt, so maybe the type should be mandatory for values above 2147483647 ? +The problem will be with the implicitly vars if the user think assigment of the 4294967295 will lead to Int64, not UInt, so maybe the type should be mandatory for values above 2147483647 ? It won't be a problem if usin only signed integer types ( Int, Int64, BigInt) + ## Alternatives @@ -56,5 +140,3 @@ Alternatives will be using Int64 literal suffix and number separator ## Unresolved questions - - From 0f321688db5dc6d75232b19ee043c8e6dcd1faf3 Mon Sep 17 00:00:00 2001 From: flashultra Date: Thu, 26 Jan 2023 14:23:28 +0200 Subject: [PATCH 3/7] More explanation of the examples --- proposals/0000-integer-data-types.md | 86 +++++++++++++++++----------- 1 file changed, 53 insertions(+), 33 deletions(-) diff --git a/proposals/0000-integer-data-types.md b/proposals/0000-integer-data-types.md index 0bc456b..1fcb36c 100644 --- a/proposals/0000-integer-data-types.md +++ b/proposals/0000-integer-data-types.md @@ -7,21 +7,21 @@ ## Introduction The current proposal have four goals: -- Replacing Int64 , UInt and UInt64 with native types (where is possible) . -- Allowing easy assignment for Int64 ,UInt and UInt64 -- Introduce new type UInt64 for all Haxe targets and use native, where is possible. -- Allowing easy conversion between integer data types. +- Replace Int64, UInt and UInt64 with native types (where possible) . +- Allows easy assignment for Int64, UInt and UInt64. +- Introduce new UInt64 type for all Haxe targets and use native where possible.. +- Allows easy conversion between integer data types. ## Motivation ### Replacing Int64 , UInt and UInt64 with native types -Some of the Haxe targets support integer types natively. +Some of Haxe's targets support integers natively. - C/C++ - - int64_t, uint32_t, uint64_t; - Java - long ; - C# - long, uint, ulong - Using native type for above targets which allowed could give better performance. + Using native types, for above targets, could give better performance. For other targets: - Pyton - numbers have unlimited size. @@ -30,56 +30,73 @@ Some of the Haxe targets support integer types natively. - Lua (>=5.3) - support 64-bit integer types ### Allowing easy assignment for Int64 ,UInt and UInt64 + +**Int64** Before Int64 literal suffix, it was more inconvenient to use Int64 (by calling Int64.make() ) and to create Int64 constant. -Still, sometimes is less readable when for example have this -```haxe - var x = 2147483i64; // this is 2147483 ( Int64) +Still, sometimes is less readable when, for example, have this +``` + var x = 2147483i64; // this is 2147483 ( Int64) var y = 2147483164; // this is 2147483164 ( Int32) ``` Using a number separator makes things better, but still be better to use ```var y:Int64 = 4294967296;``` vs ```var y:Int64 = 4294967296_i64;``` as we know the type of the variable. - At the current moment it's not possible to assign value with decimal representation above 0x7FFFFFFF ( 2147483647) for UInt - For example, the following assigment is invalid ``` var m:UInt = 3147483647;``` which is incovinient. - For UInt64 should be allowed to assign above 9223372036854775807 ( 0x7FFFFFFFFFFFFFFF) in the code. + +**UInt** + It is currently not possible to assign a decimal value greater than 0x7FFFFFFF (2147483647) to a UInt. + For example, the following assignment is invalid ``` var m:UInt = 3147483647;``` and requires the use of a hexadecimal value (0xBB9AC9FF), which is inconvenient. + + **UInt64** + For UInt64, assignment above 9223372036854775807 ( 0x7FFFFFFFFFFFFFFF) should be allowed directly in source code. ### Introduce new type UInt64 -At the moment UInt64 is introduced in C#, C++ and Eval. Should be presented in all Haxe target as emulation or as native type ( if possible) +At the moment UInt64 is introduced in C#, C++ and Eval. Should be introduced in all Haxe target as emulation or native type ( if possible) ### Allowing easy conversion between integer data types. -The current solution with the suffix give soltion for the problems like this +The current implementation of the suffix provides a solution to problems like this: ```haxe -var mask:Int64 = 1i64 << 32; +// Created mask 0000 0001 0000 0000 +var mask:Int64 = 1i64 << 32; // 0x100000000 = 4294967296 ``` but not for the problem like this: ```haxe var one:Int = 1; - var mask:Int64 = one << 32; + var mask:Int64 = one << 32; // will return 1 ``` -The following code could be rewrite like this +The above code can be rewritten like this: ```haxe var one:Int = 1; - var mask:Int64 = Int64.make(0,one) << 32 + var mask:Int64 = Int64.make(0,one) << 32; // = 0x100000000 ``` -or like +or so ```haxe var one:Int = 1; var mask = Int64.shl(one,32); ``` -Still this won't give a solution for the problem of multiplying UInt +Both ways require using Int64's internal methods. +A cleaner and easier solution would be to use suffix conversion: +```haxe + var one:Int = 1; + var mask:Int64 = (i64_t)one << 32; //convert the one variable to Int64 and do a left shift +``` +However, using Int64 internal methods, won't provide a solution for UInt multiplication ```haxe var m:UInt = 0xBB9AC9FF; var n:UInt = 0xEC7A87C6; - var mask:Int64 = m*n; + var mask:Int64 = m*n; // return 298038336 , which is Int type //or - var mask:Int64 = Int64.mul(m,n); + // For js, eval give 375817154890806330 + // Crash for Hashlink last development release + var mask:Int64 = Int64.mul(m,n); //correct value should be -5959250239385521094 + ``` -For different targets, give dfferent result, but never correct one ```-5959250239385521094``` -So if I want to multiply two UInt ( or Int) and want to receive as result Int64 is impossible in Haxe (or miss something?) . -One solution will be to add prefix before operand for the expected type ( similiar as c/c++/java/c#) which will allow and easy implementation for those targets. +It returns the wrong result in Haxe, not the correct one: +```-5959250239385521094``` +So if I want to multiply two UInts and want to get an Int64 as a result, it's impossible in Haxe. +One solution would be to add a prefix before the operand for the expected type (similar to c/c++/java/c#), which would also allow easier implementation for those targets. Example : ```haxe var m:UInt = 0xBB9AC9FF; var n:UInt = 0xEC7A87C6; - var mask:Int64 = (i64)m*n; + var mask:Int64 = (i64)m*n; //convert m to Int64 and return Int64 after multiplication //or var mask:Int64 = (i64)m*(i64)n; var mask:Int64 = m*(i64)n; @@ -109,18 +126,21 @@ Of course, the following assignment should be possible too: The other thing is Int and Int32. For some target Int could be a float ( javascript, for example), so not having a consistent overflow could lead to strange results and expectations. Not sure how many use Int and unexpected recieve Int64 value after that. Maybe it will be good to unify those two classes, but not sure how this could affect performance ( for javascript , php , python, Lua) For example ``` var b:Int = 2147483647 * 349342;``` will give 750206232210274 in JS ( 0x2AA4EFFFAAB62) -Easy conversion between different integer types could be implemented with adding preffix before the operand which will convert one int type to another. +Easy conversion between different integers can be implemented by adding a prefix before the operand that will convert one int type to another. For example : i64, u32, ui64 ; ```(i64)mask;```, ```(i32)mask;``` -Using only numbers (at the end) in the suffix and the prefix could lead to less readable code , so it could be added other alphabet such as: i64_t, u32_t, ui64_t ; ```(i64_t)mask;```, ```(u32_t)mask;``` -Other question is how to convert UInt var to Int64 -For example if have: +Using numbers (at the end) of the suffix and prefix can result in less readable code, so another letter can be added like: i64_t, u32_t, ui64_t ; ```(i64_t)mask;```, ```(u32_t)mask;``` + +Another question is how to convert a UInt variable to Int64 without to accept the first bit as a negative number to Int64 +For example, if I have: ```haxe var m:UInt = 0xBB9AC9FF; var mask:Int64 = Int64.make(0x0,m); //didn't work + // I want to have + // mask = (0x00000000 , 0xBB9AC9FF ) ``` -So we want to keep Int64.high to 0x0 and assign the UInt var only the the low part. -It's not possible in Haxe at the moment. So something like this could be allow: +So we want to keep Int64.high at 0x0 and assign UInt var only the low part. +This is not currently possible in Haxe. So something like this might be allowed in the future: ``` var mask:Int64 = (m & (i64_t)0xFFFFFFFF);``` ## Impact on existing code @@ -129,7 +149,7 @@ None ## Drawbacks -The problem will be with the implicitly vars if the user think assigment of the 4294967295 will lead to Int64, not UInt, so maybe the type should be mandatory for values above 2147483647 ? It won't be a problem if usin only signed integer types ( Int, Int64, BigInt) +The problem will be with the implicitly vars if the user think assigment of the 4294967295 will lead to Int64, not UInt, so maybe the type should be mandatory for values above 2147483647 ? It won't be a problem if using only signed integer types ( Int, Int64, BigInt) ## Alternatives From 2fdfaa8e9c04b183562fbbb1a22c9072b184df62 Mon Sep 17 00:00:00 2001 From: flashultra Date: Fri, 27 Jan 2023 15:06:38 +0200 Subject: [PATCH 4/7] Add unresolved questions Added questions about conversion between types and Int vs. Int32 types --- proposals/0000-integer-data-types.md | 41 ++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/proposals/0000-integer-data-types.md b/proposals/0000-integer-data-types.md index 1fcb36c..a4bbf2e 100644 --- a/proposals/0000-integer-data-types.md +++ b/proposals/0000-integer-data-types.md @@ -160,3 +160,44 @@ Alternatives will be using Int64 literal suffix and number separator ## Unresolved questions + +### **1) How to convert from one integer type to another?** + +There are at least two possible options: +- **Using а prefix** - Some of the lanuages use this as a solution. For example , C/C++ use long long, Java/C# uses long . Sot it is possible to introduce new prefix in Haxe, like (i64) , (i64_t) , (long) +Example: +``` +var one:Int = 1; +var mask:Int64 = (i64)one<<32; //using prefix (i64) +``` +- **Implicit conversion based on the declared type** +For example: +``` +var one:Int = 1; +var mask:Int64 = one<<32; // will return 0x100000000 +``` +As the ```mask``` expects Int64, the above code will convert ```one``` to Int64 and the result will be 4294967296 (0x100000000) . +But if we have: +``` +var one:Int = 1; +var mask = one<<32; //result is 1, as mask is Int +``` +The var ```mask``` will be converted to Int ( since we didn't specify the type and the other two operands are Int) and the result will be 1. +This solution is much clearer and replaces the need for a prefix with a declaration of the type of the result variable. +### **2) Int vs Int32** +For C,C++,Java,C# the Int type hас expected overflow behavior. For others, like Javascript, Php, Python , the numeric type defaults to 64-bit (or no limit), which leads to wrong results when the user expects an overflow. +So this will for example return 1 (or 0 if the static analyzer is on) for C/C++,Java,C#,Javascript, but 4294967296 in php (for 64bit system),Python. +```haxe + var mask:Int = 1 <<32; +``` +Note: javascript returns a correct value for bitwise operations + +Another example will return a different value for a javascript : +```haxe +var m:Int = 2147483647*2; +``` +It will return 4294967294 for Javascript , Python, Php and -2 for C,C++,Java and C# +This inconsistency between targets could lead to unexpected results. Possible solutions could be: +- Keeping things as they are now - separate Int and Int32 classes +- Set Int to have the same behavior as Int32. +This can lead to a performance loss (in javascript and possibly in python and php) for heavy arithmetic operations, but such operations will probably expect proper overflow behavior and use Int32 anyway. From cabb57f04574eb2f4964f745e5f716e6753ff6c0 Mon Sep 17 00:00:00 2001 From: flashultra Date: Thu, 2 Feb 2023 09:48:50 +0200 Subject: [PATCH 5/7] Type promotion Conversion between Float and Integer types --- proposals/0000-integer-data-types.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/proposals/0000-integer-data-types.md b/proposals/0000-integer-data-types.md index a4bbf2e..1348d67 100644 --- a/proposals/0000-integer-data-types.md +++ b/proposals/0000-integer-data-types.md @@ -1,4 +1,5 @@ + # Integer data types * Proposal: [HXP-NNNN](NNNN-filename.md) @@ -184,7 +185,24 @@ var mask = one<<32; //result is 1, as mask is Int ``` The var ```mask``` will be converted to Int ( since we didn't specify the type and the other two operands are Int) and the result will be 1. This solution is much clearer and replaces the need for a prefix with a declaration of the type of the result variable. -### **2) Int vs Int32** +### **2) Conversion from Float to Int** +The division operation of two integers would return a Float . +In Haxe that is true for the Int type, but division of Int64 will return Int64 +To convert to int the result of two int operands we should use ``Math.floor()`` as we not have a prefix ```(int)```,```(long)``` or implicit conversion between types. + One solution could be to use type promotion similiar to C , where if operand on the right hand side is of lower rank type then it becomes the type of left hand side operand as it have higher rank. +A hierarchy of this type can be: ```Int < UInt < Int64 < UInt64 < Float``` +For example , if we have: +```haxe + var operand1 = 57; + var operand2 = 6; + var result:Int = operand1/operand2; // it will return 9 + + // Same for Int64 + var operand1:Int64 = 57_i64; + var operand2:Int64 = 6_i64; + var result:Int64 = operand1/operand2; // 9 +``` +### **3) Int vs Int32** For C,C++,Java,C# the Int type hас expected overflow behavior. For others, like Javascript, Php, Python , the numeric type defaults to 64-bit (or no limit), which leads to wrong results when the user expects an overflow. So this will for example return 1 (or 0 if the static analyzer is on) for C/C++,Java,C#,Javascript, but 4294967296 in php (for 64bit system),Python. ```haxe From b8a53158c98dfce270659d4eeda09a72b7191c08 Mon Sep 17 00:00:00 2001 From: flashultra Date: Sat, 4 Feb 2023 11:32:02 +0200 Subject: [PATCH 6/7] Sign Int to unsigned Int64 conversion --- proposals/0000-integer-data-types.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/proposals/0000-integer-data-types.md b/proposals/0000-integer-data-types.md index 1348d67..ee810f6 100644 --- a/proposals/0000-integer-data-types.md +++ b/proposals/0000-integer-data-types.md @@ -187,10 +187,12 @@ The var ```mask``` will be converted to Int ( since we didn't specify the type a This solution is much clearer and replaces the need for a prefix with a declaration of the type of the result variable. ### **2) Conversion from Float to Int** The division operation of two integers would return a Float . -In Haxe that is true for the Int type, but division of Int64 will return Int64 +In Haxe that is true for the Int type, but division of Int64 will return Int64 . To convert to int the result of two int operands we should use ``Math.floor()`` as we not have a prefix ```(int)```,```(long)``` or implicit conversion between types. One solution could be to use type promotion similiar to C , where if operand on the right hand side is of lower rank type then it becomes the type of left hand side operand as it have higher rank. + A hierarchy of this type can be: ```Int < UInt < Int64 < UInt64 < Float``` + For example , if we have: ```haxe var operand1 = 57; @@ -202,7 +204,17 @@ For example , if we have: var operand2:Int64 = 6_i64; var result:Int64 = operand1/operand2; // 9 ``` -### **3) Int vs Int32** +### **3) How to convert from signed to unsigned type and vice versa?** +At the current moment conversion from Int to Int64 ( using ```Int64.ofInt()```) is sign-extended , so if you want to keep Int64 without sign we should use ```Int64.make(0x0, ) ``` or a mask ```Int64.and(,Int64.make(0x0,0xFFFFFFFF))``` . The other way will be to convert Int to UInt and after that to Int64 . + +Maybe a new prefix could be introduce for converting Int to Int64 ( no sign-extended), which will be similiar to UInt to Int64 conversion. + +Example , if have variable n = -6, we should have : +| Let n=-6 | Int | UInt | Int64
(sign-extended) | Int64
(no sign-extended) | UInt64 | Float | +|----------|-----|-----------|---------------------|------------------------|--------|-------| +|Int | -6 | 4294967290| -6 | 4294967290 | 4294967290 | -6.0 | + +### **4) Int vs Int32** For C,C++,Java,C# the Int type hас expected overflow behavior. For others, like Javascript, Php, Python , the numeric type defaults to 64-bit (or no limit), which leads to wrong results when the user expects an overflow. So this will for example return 1 (or 0 if the static analyzer is on) for C/C++,Java,C#,Javascript, but 4294967296 in php (for 64bit system),Python. ```haxe From 626b85c75f6492fa81f563a26a29ef43ca5b8f6e Mon Sep 17 00:00:00 2001 From: flashultra Date: Sun, 7 Jan 2024 21:32:44 +0200 Subject: [PATCH 7/7] Update with Int8/UInt8 proposal Adding Int8 (sbyte) and UInt8 (byte) types Adding Int16 and UInt16 --- proposals/0000-integer-data-types.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/proposals/0000-integer-data-types.md b/proposals/0000-integer-data-types.md index ee810f6..c62bcbe 100644 --- a/proposals/0000-integer-data-types.md +++ b/proposals/0000-integer-data-types.md @@ -12,7 +12,8 @@ The current proposal have four goals: - Allows easy assignment for Int64, UInt and UInt64. - Introduce new UInt64 type for all Haxe targets and use native where possible.. - Allows easy conversion between integer data types. - +- Adding Int8 (sbyte)(-127...128) , UInt8 (byte) (0...255) - for Bytes.get() +- Adding Int16, UInt16 ## Motivation @@ -102,7 +103,13 @@ Example : var mask:Int64 = (i64)m*(i64)n; var mask:Int64 = m*(i64)n; ``` +### Adding Int8 (sbyte)(-127...128) , UInt8 (byte) (0...255) +Working with ```haxe.io.Bytes``` often require to manage a single byte. Bytes.get method return a Int , which is not very memory efficient. +A new class ```Int8``` ( or ```sbyte``` ) for values between -127...128 and ```UInt8``` ( or ```byte```) for values 0..255, could be introduced. +It's possible for simplicity to have only one new type - ```byte``` ( or ```UInt8```) for values from 0...255 +### Adding Int16, UInt16 +Signed and unsigned 16-bit integer also can be introduced for working with 2bytes. ## Detailed design