In the code
residues are global constant variables (as in the C++ code).
// Global parameters
static residues: [usize; 9] = [1, 7, 11, 13, 17, 19, 23, 29, 31];
const rmod: usize = 30; // prime generator mod value
As I said, all I initially want(ed) to do was translate the working C++ version into a working Rust version. Making it idiomatically and optimally Rust can come at a later time.
The coding example shown was what was sufficient to get the Rust compiler to compile it.
If there are other alternative coding approaches I’d be happy to see them.
The larger issue I’m raising, since Rust is still young and malleable, is I think its developers should be (more) concerned how its philosophical creed affects the humans who may want to use it. The language can be both rigorous AND user friendly. These qualities need not be in conflict.
Take these examples:
let mut a = 0u8;
let mut b = 0usize;
let mut c = 0u64;
// case 1;
c = a + b;
// case 2:
b = a + c;
// case 3
a = b + c;
case 1 it should be obvious that no explicit casting should be necessary as the result takes two smaller sized values and puts their sum into a variable that can completely contain it.
case 2 probably a warning|error is applicable to note
c could overflow
b. I can see where an explicit casting as
b = a + c as usize would be necessary, but I don’t see why
a needs to be explicitly cast, for the reason stated in
case 3, where both variables exceed the size of containing variable, the same issues arises. However, this code should be valid, as the intent (to me) is to only use the lower 8 bits of the sum of the variables.
Maybe it would be better coding practice to do
case 2|3 explicitly as:
b = (a + c) as usize and
a = (b + c) as u8, with implicit temporary operational casting, or
b = (a + c) & 0xffffffff and
a = (b + c) & 0xff to show explicitly the numerical intent.
Another way is to create compiler flags (say a
fit flag) to do explicit implied numerical casting.
The ultimate point I’m trying to make, as a friendly suggestion to the developers, is to make this type of thing as easy and flexible as possible to users (people like me). I suspect people with a lot less interest AND persistence to learn this language will NOT persevere through these language qwerks. Again, the language should be subservient to the human programmer, NOT the other way around.
That is one of the major reasons people
Love Ruby. I can do so much in Ruby without having to think (worry and be frustrated) about mico implementation issues such as these. Once I know how to do what I want, I can then concern myself with speed, concurrency, scaling, etc.
I completely understand Rust is meant to be an at-the-hardware level
system programming language like C, and has different design goals and concerns than Ruby. I get that, which is why I’m taking the time to learn it, primarily based on its concurrency and memory use model. But people use and stick with
Ruby on Rail because, even with all the issues it has, you can quickly get a lot of work done with it.
I also agree with the point that vector indexes should be able to take indices other than
usize. If I have a
u8 vector it shouldn’t be restricted to only
usize number of elements, instead of
u8 or u64 number of elements as well. The type of the content should not restrict the length of the vector.
However, the divinity is in the detail. I would urge you to always think about how, ultimately, to make the language as easy to use, and think in, as possible for real people (not language designers). You’ve got a smart compiler, just make it smarter! You don’t want someone to fork your great ideas and create Rusteasy!