Re:Writing a JPEG Decoder in Rust – Part 2: Implementation I
by eddyb on Friday August 19, 2016 @06:04PM
(#12323846)
The example can be written like this though:
let codes: Vec<HuffmanCode> = data_table.iter()
.zip(&code_lengths)
.zip(&code_table)
.map(|((&value, &length), &code)| {
HuffmanCode {
length: length,
code: code,
value: value,
}
})
.collect();
Re:Writing a JPEG Decoder in Rust – Part 2: Implementation I
by Veedrac on Saturday August 20, 2016 @01:20AM
(#12325337)
In fact `code_lengths` and `code_table` are never used again so should just be passed by value, which saves four more `&`s.
Re:Writing a JPEG Decoder in Rust – Part 2: Implementation I
by saosebastiao on Friday August 19, 2016 @02:45PM
(#12322422)
Wouldn't the type guarantees provided by rusts type system allow for different implementations based on whether it was called on value types vs reference types? I thought there was an auto specialization feature created a while ago that did something like that.
Re:Writing a JPEG Decoder in Rust – Part 2: Implementation I
by Tuna-Fish on Friday August 19, 2016 @03:37PM
(#12322884)
It allows changing implementation depending on what you pass it, but it cannot change how you pass things. The issue is that if you just call zip(code_lengths), then ownership of code_lengths is passed into the function and it ceases to work in it's parent.
In effect, the "elegance" of Scala here is really the product of its heavy GC dependence. So the comparison isn't as meaningful as it might seem.