Idea: Implement FromIterator for stack allocated arrays


#1

It’d be cool to have FromIterator on stack allocated arrays - maybe once const generics become a thing. The implementation would panic if the size isn’t correct, or maybe use the default value and ignore overflow. Or, maybe even only implement it for [Option<T>; N], I don’t mind. As long as there’s something, that’d be cool!


#2

It kind of surprises me that you’re so open to different possible implementations that you’d even accept an array of Option. Wouldn’t that be difficult to work with? What do you gain out of having FromIterator work if you need to manually paper over the fact that you get Options?

Is it because you have generic abstractions that use FromIterator/collect internally? I can’t really imagine such a thing; I normally see FromIterator as an API endpoint (i.e. something to be directly used by consumers, rather than something to generalize over).

(note: if that is indeed the case, perhaps implementing FromIterator on a newtype wrapper may suffice)


#3

I don’t really have a use case where having it for [Option<T>; N] would help, I just thought it’d be cool with some love for stack allocated arrays together with iterators. Optimally we could have both behaviors, but that’d be ambigious


#4

To me this argument sounds like “because we can,” which I guess I don’t find compelling. I want the behavior of standard library constructs to be obvious.

Supposing it was only for Option, would you use it? If it discarded excess, or if it required Default, or if it panicked, would you use it?

When I want to create arrays from iterator pipelines in my own code, I make a helper function or a newtype array with the semantics I desire. I’ve had no problem with this solution and appreciate the clarity it provides.


#5

I have a use case for a defaulting FromIterator implementation. I can see a use case for Option too, for example if you want to rewind and index an iterator that is probably smaller than a specific size but don’t want to allocate