21–30 of 183 posts
Earlier quoted context omitted.
You can't mutate variables in rust without declaring mut
But how do you know just by reading that code? It would not be obvious to me at all.
> the escape hatch suggested on the internet, `partial_cmp(...).unwrap_or(Ordering::Less)` This is often a Bad Idea, as you get unstable sorts and you are right back to the same problem. - Explanation: How do I get the minimum or maximum value of an iterator containing floating point numbers? — https://stackoverflow.com/a/50308360/155423 - Example: https://play.integer32.com/?version=stable&mode=debug&editio... See a…
Isn't there a default total order for floats? E.g. -Inf < -1.0 < -0.0 < 0.0 < 1.0 < Inf < NaN?
It is not something to use by default though. It is implemented in software and thus a lot slower than the hardware comparison.
I've not done any rust dev before but the whole variable shadowing thing really scares me, in that it makes it not obvious where the initial declaration comes from. This seems difficult to reason about.
It probably helps that the only ways to introduce new variables are all very distinctive:
let [new variables] = [expr];
if/while let [new variables] = [expr] { [new variables scoped here] }
for [new variables] in expr { [new variables scoped here] }
fn name([new_variables]) { [new variables scoped here] }let foo = "..."; let foo = parse(foo); let foo = escaped(foo); Is it really shadowing or mutation of foo? I would consider this shadowing (something you can do in OcaML): let foo = "..." in let foo = parse(foo) in let foo = escaped(foo) in dosomething(foo);;
Earlier quoted context omitted.
You can't mutate variables in rust without declaring mut
But how do you know just by reading that code? It would not be obvious to me at all.
is shadowing
let foo = bar; foo = bat;
is a compilation-time error because foo isn't mutable.
let mut foo = bar; foo = bat;
is reassignment.
in working code, either foo is declared as mutable or it's not, and it's pretty obvious from the code what's happening.
I would prefer it if this feature didn't exist at all rather than cause runtime panics.
https://play.rust-lang.org/?gist=e02ce5e9aacfee3a2b4917d5624...
Earlier quoted context omitted.
Isn't there a default total order for floats? E.g. -Inf < -1.0 < -0.0 < 0.0 < 1.0 < Inf < NaN?
No, because x NaN are false for any value of x.
Earlier quoted context omitted.
Isn't there a default total order for floats? E.g. -Inf < -1.0 < -0.0 < 0.0 < 1.0 < Inf < NaN?
Yes, there is: https://en.wikipedia.org/wiki/IEEE_754#Total-ordering_predic... It is not something to use by default though. It is implemented in software and thus a lot slower than the hardware comparison.
I've not done any rust dev before but the whole variable shadowing thing really scares me, in that it makes it not obvious where the initial declaration comes from. This seems difficult to reason about.
The GNU C library (needed not only by C programs for C things) doesn't support static linking, so the only way this is possible is to use another library entirely, or raw inlined syscalls (where applicable).