Std library inclusion policy

[leonardo]

This is a spinoff of a discussion from:

Issue: Tracking issue for Iterator::flatten

In my opinion the current strategy used to chose what iterables to add to the Rust standard library isn’t good enough. In my opinion adding iterators is not free, the more there are the higher cognitive load for the programmer there is and the time to find the right function grows. So functions should be added on the base of data. One way to look for such data is to measure in some way what itertools functions are more used. Instead of flatten() there are more commonly useful iterators to add to the std library.

[Centril]

Instead of flatten() there are more commonly useful iterators to add to the std library.

That is your view… .flatten() was explicitly requested instead of .flat_map(|x| x) on an RFC about identity and many wanted it… The operation is also a fundamental operation as it is monadic join… It seems to me strange that bind and functor mapping should be there but not join…

My general view is that the standard library should provide a strong algorithmic foundation to build things upon and iterators are key here - I think there’s room to grow in std::iter.

To reduce the cognitive load, we should better support signature based searching - a type of a function can very often tell you a lot about its semantics… at least, that is what I’ve found with hoogle & Haskell.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.