strcmp() returns an integer indicating the result of the comparison, as follows:
0, if the s1 and s2 are equal;
a negative value if s1 is less than s2;
a positive value if s1 is greater than s2.
So basically, if C had higher level constructs, it would be identical to Rust here.
So, even if it is cool to manipulate strings by using addition/subtraction, it is still bad language design and very unintuitive.
Rust has implAdd<&str> forString and implAddAssign<&str> forString. Both append as expected.
But maybe you meant numeric addition specifically.
In that case, yes, Rust doesn’t have that, although it’s an impl<'a> Step for &'astr away from having something similar (it would be ("AAAAA"..).next()).
implStepforchar already exists of course, but shouldn’t if we take your argument to its logical conclusion.
Oh, and C would most definitely have this feature if it could. Numerical manipulation of chars is commonplace there.
Rust has impl Add<&str> for String and impl AddAssign<&str> for String. Both append as expected.
I wouldn’t go so far and say “as expected”: “Addition” implies that we’re dealing with a ring, that there’s also multiplication, and that really doesn’t make sense for strings (unless you indeed consider them numbers). It’s why Haskell’s Monoid typeclass comes with the function mappend, not madd.
In Rust’s defence though std::ops traits aren’t meant to carry any semantics they’re about syntax: It’s called Add because it’s +, not because it means something. I do think it would’ve been worth it to introduce ++ for general appending (also vectors, sets, maps, etc), though, to keep things clean. Also ++= for the mutating case.
I do think it would’ve been worth it to introduce ++ for general appending.
I already mentioned (val..).next() which is both safe* and explicit about it being a generic stepping operation instead of possibly being sugar for {x = x + 1; x}.
Also, calling it “appending” is weird for us folks coming from languages like C 😉
* you don’t have to worry about what i32::MAX++ would/should return.
Pre- and post-increment are only really useful when you’re doing C-style looping and there’s a good reason we don’t do that in Rust.
I actually honestly can’t recall ever making an off by one error in Rust, I’m sure when implementing specific data structures or when doing pointer manipulation it’s still a possibility but you can write a gazillion lines of code without ever running risk of that particular annoyance. Also while C folks may have an argument regarding operator semantics, C++ folks don’t they’re doing unspeakable things to <<.
Also, FWIW Haskell uses ++ to append lists and therefore also strings. It’s not like it’s an odd-ball usage of the symbols, that’d be .. which I vaguely remember some language using. Would cause a whole new class of confusion regarding 'a'..'z' vs. "a".."z". Not to mention that "aa".."zz" actually makes sense as a range all that’s missing is &str: Step. Probably not a good idea to have built-in because do we mean printable ASCII? Whole unicode range? Just the alphabet? Not an issue when you’re doing it to single chars but strings get ambiguous fast. Does Rust even guarantee stuff about Char ordering C certainly doesn’t really do that, short of I think 0..9 being contiguous.
The general theme of your comment is good, but the example is…
// rust eprintln!("{}", "AAAAB" > "AAAAA") // true eprintln!("{}", "Mark" > "John") // true// C printf("%d\n", strcmp("AAAAB", "AAAAA")); // 1 printf("%d\n", strcmp("Mark", "John")); // 1strcmp()docs:So basically, if C had higher level constructs, it would be identical to Rust here.
Rust has
impl Add<&str> for Stringandimpl AddAssign<&str> for String. Both append as expected.But maybe you meant numeric addition specifically.
In that case, yes, Rust doesn’t have that, although it’s an
impl<'a> Step for &'a straway from having something similar (it would be("AAAAA"..).next()).impl Step for charalready exists of course, but shouldn’t if we take your argument to its logical conclusion.Oh, and C would most definitely have this feature if it could. Numerical manipulation of
chars is commonplace there.I wouldn’t go so far and say “as expected”: “Addition” implies that we’re dealing with a ring, that there’s also multiplication, and that really doesn’t make sense for strings (unless you indeed consider them numbers). It’s why Haskell’s
Monoidtypeclass comes with the functionmappend, notmadd.In Rust’s defence though
std::opstraits aren’t meant to carry any semantics they’re about syntax: It’s calledAddbecause it’s+, not because it means something. I do think it would’ve been worth it to introduce++for general appending (also vectors, sets, maps, etc), though, to keep things clean. Also++=for the mutating case.I already mentioned
(val..).next()which is both safe* and explicit about it being a generic stepping operation instead of possibly being sugar for{x = x + 1; x}.Also, calling it “appending” is weird for us folks coming from languages like C 😉
* you don’t have to worry about what
i32::MAX++would/should return.Pre- and post-increment are only really useful when you’re doing C-style looping and there’s a good reason we don’t do that in Rust.
I actually honestly can’t recall ever making an off by one error in Rust, I’m sure when implementing specific data structures or when doing pointer manipulation it’s still a possibility but you can write a gazillion lines of code without ever running risk of that particular annoyance. Also while C folks may have an argument regarding operator semantics, C++ folks don’t they’re doing unspeakable things to
<<.Also, FWIW Haskell uses
++to append lists and therefore also strings. It’s not like it’s an odd-ball usage of the symbols, that’d be..which I vaguely remember some language using. Would cause a whole new class of confusion regarding'a'..'z'vs."a".."z". Not to mention that"aa".."zz"actually makes sense as a range all that’s missing is&str: Step. Probably not a good idea to have built-in because do we mean printable ASCII? Whole unicode range? Just the alphabet? Not an issue when you’re doing it to single chars but strings get ambiguous fast. Does Rust even guarantee stuff about Char ordering C certainly doesn’t really do that, short of I think0..9being contiguous.