Tracking issue for TrustedLen (`trusted_len`)

[bluss]

Implemented in #37306

Open Questions:

• • Naming: something with Iterator in the name?
• • Naming: size vs len
• • Does TrustedLen pose any requirements on the ExactSizeIterator impl if one exists for the same type?
• • Does TrustedLen pose any requirements on the Clone impl if one exists for the same type?
• • Check all the specific impls, including complicated ones like Flatten on arrays or FlatMap that returns arrays.

[est31]

Oh, finally this thing is there!

I was avoiding collect() like the plague because of this missing.

[photino]

I think it is better named TrustedLenIterator, since we don't call ExactSizeIterator as ExactSize.

[jethrogb]

Or perhaps TrustedSizeIterator?

[cyplo]

As the referenced code is merged - is this still an issue ? thank you !

[bluss]

Yes, tracking issues keep note on the code while it is still an unstable feature; they are closed when the feature is stabilized or removed.

[alexbool]

By the way, what is holding stabilization right now?

[vadixidav]

I feel that ExactSizeIterator should be addressed in the documentation for TrustedLen. Although the default implementation should be correct, TrustedLen should also specify that any override in ExactSizeIterator (or rather that the trait overall) should also fulfill the contract to be implemented.

Any thoughts?

[ishitatsuyuki]

Do we need a RFC for stabilization? Also, is TrustedLen meant to be the successor (replacement) of ExactSizeIterator?

[bluss]

It serves a different purpose, so I don't think it is a successor. Good start towards stabilization would be to incorporate the naming suggestions from this tracking issue I think.