Is interpolated strings possible in rust? like https://docs.microsoft.com/en-us/dotnet/articles/csharp/language-reference/keywords/interpolated-strings
in C# you'd do: $"{p.First} {p.Last} is {p.Age} years old."
it's done via macro like (from that page)
format!("Hello"); // => "Hello"
format!("Hello, {}!", "world"); // => "Hello, world!"
format!("The number is {}", 1); // => "The number is 1"
format!("{:?}", (3, 4)); // => "(3, 4)"
format!("{value}", value=4); // => "4"
format!("{} {}", 1, 2); // => "1 2"
format!("{:04}", 42); // => "0042" with leading zeros
that's not how interpolated strings work in C#
It's more of a
printf style than directly putting it inline in the strings.
you can't do
let value = 4; format!("{value}"); in rust as far as I know
rust-lang/rfcs#1250
why is this not possible?
for index in 3..0 { }
why isn't it possible to join or concat on a iterator?
in C# you can do String.Join("seperator", whatever-enumerable);
for index in (0..3).rev() { }
You can use itertools crate https://docs.rs/itertools/0.6.0/itertools/trait.Itertools.html#method.join
As for 'why', it requires too much speculation to answer.
let result: Vec<String> = (verse_to..(verse_from+1))
.rev()
.map(|i| (&verse(i)).clone())
.collect::<Vec<String>>();
result.as_slice().join("\n")var result = String.Join("\n", Enumerable.Range(verseFrom, verseTo).Reverse().Select(i => verse(i));
how it would look in C#
What type does
verse return?
a String
Then you don't need
.map(|i| (&verse(i)).clone()) and should be able to use .map(verse)
actually it could be written as
let result = (verse_to..verse_from+1).rev().map(verse).collect::<Vec<_>>().join("\n")
thx
In c# you dont need to
.Select(i => verse(i)) to :P You can write just .Select(verse)
tru dat
why is
.collect::<Vec<_>>() necessary? I mean why isn't it possible to join on an iterator?
@snarf95_twitter It is actually possible. As @red75prime wrote, itertools has a
join method. It's just not in the standard library (yet).
@snarf95_twitter
Why it isn't implemented in standard library? I don't know. Maybe no one deemed it important enough to submit a PR to include it.
join for Iterator<Item=U>, U: Copy can be implemented relatively easily https://play.rust-lang.org/?gist=8339f4b984ba66df8c84c973eb282ed8&version=stable&backtrace=0Why it isn't implemented in standard library? I don't know. Maybe no one deemed it important enough to submit a PR to include it.
itertools has join https://docs.rs/itertools/0.6.0/itertools/fn.join.html which might be one reason why I can't find an RFC or PR for this to be in std
why can't I do
(1..range_end).sum()?
@snarf95_twitter You should be able to, what's the error message?
let s: i32 = (1..20).sum();
the trait
std::iter::Sum<u8> is not implemented for u32
Okay, so you're trying to sum a bunch of
u32s into one u8?
That seems like a bad idea :D
no its the other way around u8 -> u32
oohh, right
That's interesting that that doesn't work
convert u8 into u32.
.map(|v|v as u32).sum() or .map(|&v|v as u32).sum()
thx
It is weird that there are no
impl Sum<uX> for uY where X < Y
that sure would be convenient
Why must I call iter() on a vec?
Because no method overloading right? But why no method overloading?
@snarf95_twitter calling
.iter() on any collection will create you a value that keeps track of the position inside the vec for example; if this was a feature of the collection itself you couldn't have multiple iterators created to the same collection at the same time
@snarf95_twitter No, it is because Vec implements IntoIterator using move semantics (items are moved out of it). iter() returns an Iterator that has reference semantics (references items within the Vec, doesn't move them out)
I see... it's just that it makes code look more cluttered than it needs to be, when you're only querying the vec...
im not sure I understand tbh, if the vec is immutable then move shouldn't be possible right?
@snarf95_twitter i remember being confused about these as well: owned values can be moved or borrowed,
mut allows borrows, mutable borrow and mutation. they are more orthogonal than on the same axis
Your variable (aliasing the vec) is immutable, so the Vec can't have any of its mutating methods called on it. That is not the same as move. An immutable variable can be moved (it's not being mutated, it's being consumed). Vec's IntoIterator moves the Vec into its
into_iter() method, consuming it. So that means items inside of Vec are no longer owned by the Vec and can/will be moved out (otherwise they will be dropped).
Hey Rustceans, are there any decent free resources that are good for learning Rust? Learn Rust in Y Minutes isn't...well very helpful. exercism.io is great if I knew the structure of Rust better.
@pnkfelix sweet! Thanks!
pub fn encode(input: &str) -> String {
let runs = input
.chars()
.fold(Vec::<(char, u8)>::new(), |mut acc, c| {
if let Some(last) = acc.iter().cloned().last() {
if last.0 == c {
acc.pop();
acc.push((last.0, last.1 + 1));
} else {
acc.push((c, 1));
}
} else {
acc.push((c, 1));
}
acc
});
runs.iter()
.map(|x| if x.1 > 1 {
format!("{}{}", x.1, x.0)
} else {
format!("{}", x.0)
})
.collect::<Vec<_>>()
.join("")
}acc.iter().cloned().last() - don't do that, it'll kill your performance!
You need to split up the borrow of
acc into two parts - one where you get (and copy) the character to test against, and one to actually edit acc.
But the last element is copy :)
pub fn encode(input: &str) -> String {
let mut chars = input.chars();
match chars.next() {
None => "".to_string(),
Some(first_char) => {
let initial_state = vec!((first_char, 1));
let runs = chars.fold(initial_state, |mut acc, c| { // acc is never empty
let &(last_char, _) = acc.last().unwrap();
if last_char == c {
(*acc.last_mut().unwrap()).1 += 1
} else {
acc.push((c, 1))
}
acc
});
runs.iter() // from here on the same as yours
woah thats awesome, thanks
The
initial_state thing isn't strictly necessary but it's a lot cleaner and could potentially be more efficient (but I suspect all those if acc.len() == 0 checks would get optimised out anyway).
Actually since you're mutating
acc anyway the fold is redundant and can be replaced with a loop:pub fn encode(input: &str) -> String {
let mut chars = input.chars();
match chars.next() {
None => "".to_string(),
Some(first_char) => {
let mut acc = vec!((first_char, 1)); // acc is never empty
for c in chars {
let &(last_char, _) = acc.last().unwrap();
if last_char == c {
(*acc.last_mut().unwrap()).1 += 1;
} else {
acc.push((c, 1));
}
};
acc.iter()
.map(|x| if x.1 > 1 {
format!("{}{}", x.1, x.0)
} else {
format!("{}", x.0)
})
.collect::<Vec<_>>()
.join("")
}
}
}
To do it "functionally" with a fold without mutation is a different question. You'd want some kind of
group function that splits chars into blocks of the same char.
extern crate itertools;
use itertools::Itertools;
fn main() {
let groups = "aabccccccdaasd".chars().group_by(|&c|c);
let res: String = groups.into_iter().map(|(c, i)| {
let len = i.count();
if len == 1 {
format!("{}", c)
} else {
format!("{}{}", len, c)
}
}).collect();
println!("{:?}", res);
}
That is some sweet code
Although it's less efficient.
i.count() traverse group of chars second time.
What's the type of i?
Can't you do is_empty or any?
it's
itertools::structs::Group, essentially it's iterator
Each
i is your group of chars, i.e. aaa, bb or the like. So unfortunately you do need to count them.
Hmm
As a further optimisation to my last version with the loop, you could store the
Vec<String> and keep the "last" element in a mut (char, u8) directly instead of storing the intermediate Vec<(char, u8)> and then converting to the Vec<String> in a second pass.
Yeah I would prefer to stick with higher level functions but apparently rle is making it difficult. Would a peekable iterator help?
@red75prime Are you sure
i.count() traverses them the second time and not the first?
I mean if you really want to do things purely you could try the last of the solutions here: https://wiki.haskell.org/99_questions/Solutions/10
Thx and yeah you might be right about count
Where instead of having
acc be mutable and you append to it, you create it by chaining closures. (I think).
But you have two options: a super nice solution that might be slower (using
group_by) or a manual and mutable solution that will probably be faster.
It might get optimised out anyway, unless this was a performance bottleneck I'd always go with @red75prime 's solution
Thx I'm actually just trying to learn rust through exercism.io
Sure, but it's worth thinking about the speed/clarity (maintainability) trade-off.
Absolutely but I think you can produce some really nice code using higher order functions. I'm coming from a c# background and maintainability is everything.
If this was for production, you'd probably make a run length iterator?
Using lower level code
@snarf95_twitter Note that higher order functions are not always a win in maintainability, and a concise loop may be much more readable sometimes...
I think that the maintainability might not be too bad if you split the logic so that you had the loop be its own function:
fn encode(input: &str) -> Vec<(char, u8)>
But you'd still need a reason to do that over
group_by IMO.