You are reading content from Scuttlebutt
@Daan %ptxY1I9Quaq4NFblq9SAMk8hqzLoKyLhuvU1s3Y6DXg=.sha256
let e1: &&&' static Emoji = ...

Somewhere, I made some very terrible decision 🙈

@Daan %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 maps 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. 😆

@aljoscha %vykC0icOSUxgtqGJo4UEwSRBkJVX1kNseFaeOaTUyFs=.sha256

@Daan Patchwork

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 mapping Emoji::clone over the iterator obtained from Vec::iter.

User has not chosen to be hosted publicly
Join Scuttlebutt now