C# has primitive integer types that match (most of) Rust's primitive integer types, i.e. it has signed and unsigned 8, 16, 32, and 64 bit integer types. However, it's generally considered a best practice in C# to only use byte, short, int, and long as unsigned integer types are not CLS-compliant.
The goal is to generate idiomatic C# as much as possible, and it's considered a best practice to prefer int over the other integer types. So the question I'd like to answer is whether we should use the more directly type matchups (e.g. u32 becomes uint) or the more idiomatic approach (e.g. u32 becomes int).
My suspicion is that we'll have to allow both, so I guess it's more a question of what the defaults should be and how to allow users configure the generated code. My thoughts at the moment are:
Generate idiomatic bindings by default, so int or long everywhere.
Use attributes on functions/parameters/returns to tweak the code generation in specific cases.
Provide global configuration for code generation via command line arguments (possibly including a configuration file format).
There's also the question of how usize/isize should be handled. Since they don't have a consistent bit width across platforms its not clear how to best represent them in C#. Again, the idiomatic thing to do would be to use int for them by default, but there will definitely be cases where a different integer type is more appropriate, so allow users to configure the generated code would be ideal.
C# has primitive integer types that match (most of) Rust's primitive integer types, i.e. it has signed and unsigned 8, 16, 32, and 64 bit integer types. However, it's generally considered a best practice in C# to only use
byte,short,int, andlongas unsigned integer types are not CLS-compliant.The goal is to generate idiomatic C# as much as possible, and it's considered a best practice to prefer
intover the other integer types. So the question I'd like to answer is whether we should use the more directly type matchups (e.g.u32becomesuint) or the more idiomatic approach (e.g.u32becomesint).My suspicion is that we'll have to allow both, so I guess it's more a question of what the defaults should be and how to allow users configure the generated code. My thoughts at the moment are:
intorlongeverywhere.There's also the question of how
usize/isizeshould be handled. Since they don't have a consistent bit width across platforms its not clear how to best represent them in C#. Again, the idiomatic thing to do would be to useintfor them by default, but there will definitely be cases where a different integer type is more appropriate, so allow users to configure the generated code would be ideal.