4 ms·

The whole IntoIterator for arrays issue was that there was existing code using IntoIterator of the slice deref, which was incompatible with an array IntoIterato

by pitaj 5y ago

The 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 ago
That would require into_iter to behave differently from every other method.
- pitaj 5y ago
  I 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 ago
    Then 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 ago
      Right 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".

by pitaj 5y ago

pie_flavor 5y ago

That would require into_iter to behave differently from every other method.

pitaj 5y ago
I 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 ago
  Then 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 ago
    Right 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".