Add Various Zip-Related Types and Operations

[anandabits (Matthew Johnson)]

@Ben_Cohen

The implementation the author uses instead:

let (texts, labels): ([String], [String]) =
    corpus.reduce(into: ([], [])) { (columns, row)
        columns.0.append(row.text)
        columns.1.append(row.label)
    }

is sub-optimal since it doesn't reserve space up-front. But doing that would in turn rule out using reduce(into:) , maybe hurting readability.

The fact that pre-allocation of space rules out reduce(into:) is a gap in that API that I pointed out in the discussion and review of that proposal. The conversation about this in the discussion thread started here: Reduce with inout - #37 by anandabits. There was also quite a bit of conversation in response to my review of that proposal: SE-0171: Reduce with inout - #5 by anandabits

I think we should fill the gap that prevents an efficient and straightforward eager implementation of unzip from being written outside the standard library rather than accept a proposal like this one on the grounds that an efficient solution is not straightforward.

Regarding the proposal itself, I think it would be more inline with the rest of the standard library if unzip were lazy rather than eager. It does not make use of a closure and is similar in nature to enumerated and reversed.

I think the proposal should provide concrete motivating use cases for zipLongest. I am specifically curious as to whether they would benefit from a design that retained information about the "common prefix" with a non-optional pair values (i.e. the result when the usual zip is used). If so, perhaps LongestSequenceshould also providecommonPrefixandpartialSuffix` views (these are straw man names).