3 ms·
On the IntoIterator topic: I do think it was a mistake to `impl IntoIterator for &[mut] T` for the collections. I think it would have been better to just standa
by pitaj 5y ago
On the IntoIterator topic: I do think it was a mistake to `impl IntoIterator for &[mut] T` for the collections. I think it would have been better to just standardize on `.iter[_mut]()` instead. Would have avoided the whole "IntoIterator for arrays" issue and would be more explicit.
- epage 5y agoFor me, the reason I like an explicit `.iter()` is because its more refactor-friendly. If I have an existing loop over `&collection` but want to call an iterator method, I have to switch to `collection.iter().enumerate()`.
- pie_flavor 5y agoAnother thing that would have avoided the whole 'IntoIterator for arrays' issue would have been implementing IntoIterator for arrays. What benefit would your version provide over the 2021 edition as-is, and why would it be worth the major consequence of fracturing the iterator system into T, &T, and &mut T, as opposed to &T and &mut T just being special cases of T?
- pitaj 5y agoThe whole IntoIterator for arrays issue was that there was existing code using IntoIterator of the slice deref, which was incompatible with an array IntoIterator impl that would take precedence. A compiler hack was introduced to hide the array implementation on older editions. Requiring `.iter()` to get a reference iterator install of just doing it automatically would have avoided the need for a hack.
- pie_flavor 5y agoThat would require into_iter to behave differently from every other method.
- pitaj 5y agoI have no idea what you mean by this. Currently the following impls exist: (1) `Vec<T>`, `HashMap<T>` (2) `&[T]` (equiv to `slice.iter()`), `&HashMap<T>` (equiv to `map.iter()`) (3) `&mut [T]` (equiv to `slice.iter_mut()`), `&mut HashMap<T>` (equiv to `map.iter_mut()`) All I'm saying that `IntoIterator` should only be used for owned iterators, and it should be standard to provide `.iter()` and `.iter_mut()` for producing reference iterators. That is, only the (1) impls should exist, and the (2) and (3) impls should not. I don't understand how that requires it to act differently from every other method.
- pie_flavor 5y agoThen I misunderstood you, but now you have driven a fence between types that can be converted to iterators and types that implement IntoIterator. The purpose of IntoIterator is to describe a type that can be converted into an iterator; deliberately not implementing it for types that can, just so that there's no confusion for someone calling into_iter on a reference, does not seem like a net positive. I doubt anyone would have ever complained about references implementing IntoIterator if arrays had just implemented it from the start. Like I said, the only problem that's been brought up doesn't need a solution other than the one that's already been implemented.
- pitaj 5y agoRight my point is that IntoIterator should not just mean "this can be iterated over". It should instead mean "this owned type can be converted into an iterator of its elements".
- pavon 5y agoI'm just relearning Rust after first using it in the pre-1.0 days. Predicting what kind of iterator I'm going to get in what circumstances has definitely been a stumbling block for me. Sometimes it makes sense in retrospect (String::chars() must be producing copies not references, because it doesn't hold data as char internally, duh), but it is an area of the language where I frequently get unexpected compiler compiler errors.