Rust's handling of numeric conversions is broken IMO. Implicit conversions to wider types that never overflow should be allowed, and the "as" operator shouldn't silently ignore overflow. I should also be allowed assume that usize is at least 32-bit, instead of requiring a fallible conversion. I really doubt pervasive support for 16-bit architectures is important enough to justify inconveniencing everyone else.
Coming from Ada and its bounded integer and floating point (and fixed points, in the standard) operations defined by type, with explicit conversions, I disagree. The correct typing of variables of physical characteristics and their operators has saved my ass so many times, and the use of static and runtime checks is a boon in scientific code. Sadly our internal math library isn't amenable to dimensional analysis, or it would also be another great bug buster. Look up 'gnat' https://gmpreussner.com/research/dimensional-analysis-in-pro... and follow the links.
Of course nobody prevents you from using Float, Long_Float, Integer everywhere, but it is actually discouraged. Define a specific type. Is it a count, a speed, a quantity of apples, a modular value (i.e. you actually want wraparound semantics), what is its minimal value, its maximum value... The actual binary representation is more of an implementation detail (and can be coerced to do many, many things through 'aspects' or pragmas or just representation clauses.
If I could change one thing there, it's the operator visibility rules, which a perennial compaibt of the Ada developer. But, to dissent from my Adaist brethren I'd ask the standard to go to more explicit operator choice. Make it explicit in the code and for those with RSI make the IDE do the inference and print it in the darned code. Please?
As far as I can tell, the correct way to handle units of measurement in a programming language is by extending unification to abelian groups, as in Andrew Kennedy's work that was later implemented in F#:
This seems superior to the GNAT solution. And support for dimensionality is somewhat orthogonal to the ergonomics of converting e.g. a u32 to a u64 that comes up in systems programming.
You're right that it is orthogonal to the size of the variable, but thinking in bounds, precision, and yes, types (that can carry many notions, including dimensionality) is more interesting, to me, than 'just' u32 to u64. In my experience, being prompted to think about what you actually mean and have a tool to express it and check it is a good way to write understandable and correct code.
16bit microcontrollers are pervasive in "embedded industries" and greatly benefit from rust memory safety. that's why adacore and AUTOSAR officially try to gather some rust (hrm).
that said, rust indeed should work on fixing numeric conversion, not just for these small word sized but for everybody.
