%ptxY1I9Quaq4NFblq9SAMk8hqzLoKyLhuvU1s3Y6DXg=.sha256
let e1: &&&' static Emoji = ...
Somewhere, I made some very terrible decision 🙈
%ptxY1I9Quaq4NFblq9SAMk8hqzLoKyLhuvU1s3Y6DXg=.sha256
let e1: &&&' static Emoji = ...
Somewhere, I made some very terrible decision 🙈
%4SI9lz4HmMgJORlVfOL2w3IMkIxFY49eiKICVRw5Ofs=.sha256
Honestly I think it's mostly a problem of me not understanding iterators enough, or not knowing the right calls to make on these. I start with a Vec<&Emoji>
and end up with Vec<&&Emoji>
and then I call itertools::combinations(2)
and some map
s in the middle somewhere and boom, I end up with this kind of abomination. At least #rustlang seems to figure out by itself that it needs to triple-deref these before it can extract any meaningful things from the struct. 😆
%vykC0icOSUxgtqGJo4UEwSRBkJVX1kNseFaeOaTUyFs=.sha256
Do you need your initial Vec of Emoji to keep existing after obtaining you derived collection? If not, you can use Vec::into_iter, which takes ownership of the original Vec
(i.e., you cannot use it anymore afterwards), but which yields Emoji
rather than &Emoji
like the iterator obtained via Vec::iter
. Writing for emo in my_vec {...}
desugars to using the by-reference iterator from Vec::iter
(emo
has type &Emoji
), whereas for emo in my_vec.into_iter() {...}
iterates by values (emo
has type Emoji
).
If you need to keep the original collection, try map
ping Emoji::clone
over the iterator obtained from Vec::iter
.