[swift-evolution] Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib

[David Rönnqvist]

> > On Jan 10, 2016, at 10:20 PM, Kevin Ballard via swift-evolution<swift-evolution at swift.org>wrote:
> > 
> > When the proposal is "we have a bunch of functions that match functions used in other languages, lets add a few more from the same category of functions that we missed", does there really need to be much explanation beyond "they're useful in the other languages that have them, they'd be useful for the same reasons in Swift”?
> I agree with what you’re saying, but the flip-side is: how do we scope what we accept into the standard library? Just existing in some other language doesn’t mean that we should (automatically) accept new standard library functionality.
> 
> I’m not arguing for or against your proposal, just trying to say that this rationale isn’t enough to justify adding things to the Swift standard library.
> 
> -Chris
> 

I agree with both of you: that these are useful additions, but also that it’s important to know where to draw the line.

Sorry if this is not the place for this discussion (my first post in this mailing list):
I feel that one way of moving this discussion forward is by looking more generally at what justifies adding new functionality that is similar to existing functionality.

One part of that discussion is how the new additions would serve the broader goals of the language.

 - Is this a style that the standard library wants to encourage?
 - Why (to serve what goal) was the existing functionality added in the first place?
 - Does this addition continue to serve some of the goals of that addition? 
For this proposal it would be useful to know a little bit more about the original discussion about woking with sequences in a functional manner and adding `map`, `filter`, `reduce` etc. to the standard library in the first place, since the proposed additions also relate to woking with sequences in a functional manner
For this proposal it might also be helpful knowing some of the reasoning behind adding `prefix`, `suffix`, `dropFirst`, and `dropLast`, since the proposed additions have similar functionality.

Another part of that discussion is how the new functionality relates to the existing. 

If the new is more is more general than the existing, then what other useful additions could be implemented with this new? It might be interesting to reverse the question and ask if the existing would be added if the new proposed function already existed.

If the new is a specialization of something existing, then is it something that many developers will end up implementing themselves? I would see this as a good reason to implement it in the standard library. Even more so if there is a high risk that individual implementations will have subtle differences in behavior or a high risk of bugs in the individual implementations. 

David