In #rustlang, I'm zipping two arrays to get an iter of tuples, but it's coming out as (&i32,&i32) and I really want (usize,usize) so I can use those as array indexes. Is there a way to do this without explicitly doing "myarr[*x as usize][*y as usize]" ?
-
-
-
Replying to @rustlang @KevinHoffman
Can we get something like .copied() that would only work with Copy types? Then one could make sure they don’t accidentally clone expensive things, e.g. in generic code.
1 reply 0 retweets 0 likes -
I think it's super confusing to have clone + copy in the same language. In Rust it's okay because Copy only means that the object can be cloned instead of move. The compiler teach you that. But when you have 2 methods: copy & clone, I find it confusing
1 reply 0 retweets 1 like -
I'm not talking about having a .copy() method on Copy types, I'm talking about having a .copied() method on Iterators with Items that are Copy. It would allow for additional safety: if I have my_items.iter().copied() somewhere, it would break if I change the type to not be Copy
1 reply 0 retweets 0 likes -
Replying to @despawnerer @CecileTonglet and
...whereas if it's just my_items.iter().cloned(), for Copy types that's cheap (by definition), but I can very easily change the underlying type to not be Copy anymore and I miss the potentially expensive cloning somewhere else
1 reply 0 retweets 0 likes -
Ahhh I understand your point now. Though I wonder where you saw that Copy is cheap by definition? I checked the doc to see how they suggest to use the trait, they say a type should derive it if it can. But I can't find the idea that a Copy type is cheap https://doc.rust-lang.org/std/marker/trait.Copy.html …
1 reply 0 retweets 0 likes -
Huh, you’re right, it doesn’t say that. I was sure it did. It does make sense to me though that Copy types would be at least expected to be cheap to copy at least, since it’s so easy to do and it’s just a memcpy underneath. I guess with big structs it could be more expensive.
2 replies 0 retweets 0 likes -
It should say that, please file a bug! Copy is *always* a memcpy of the exact bits of the thing you’re copying; a “shallow” copy
1 reply 0 retweets 0 likes -
Since Copy requires Clone I thought it was using the Clone implementation. Good to know!
1 reply 0 retweets 0 likes
No problem! It’s the other way around; since Clone is more complex, if you’re Copy, then Clone must exist and be equivalent to it. You can be Clone and not Copy but not Copy and not Clone :)
-
-
I thought for a second that it was weird to have 2 different implementations for clone and copy but then I realized that actually we use them very differently too... makes sense!
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.