[swift-evolution] Proposal: Add SequenceType.first

[Andrew Bennett]

Related to this I've been toying around with a tweak to GeneratorType - it
could clear up some of the issues with .first consuming part of the
sequence:

public protocol NewGeneratorType {

    typealias Element

    func next() -> (value: Element, state: Self)?

}


extension NewGeneratorType {

    mutating func next() -> Element? {

        let nextPair: (value: Element, state: Self)? = self.next()

        if let state = nextPair?.state {

            self = state

        }

        return nextPair?.value

    }

}


I haven't had time for a proposal yet, but thought I'd mention it as it
seemed relevant.



On Thu, Dec 31, 2015 at 7:40 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> -Dave
>
> On Dec 30, 2015, at 5:00 PM, Kevin Ballard via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Wed, Dec 30, 2015, at 04:39 PM, Daniel Duan wrote:
>
> Here it is
> https://github.com/apple/swift/blob/master/stdlib/public/core/CollectionAlgorithms.swift.gyb#L26
>
>
> On Dec 30, 2015, at 4:27 PM, Kevin Ballard <kevin at sb.org> wrote:
>
> We already don't have a .last on CollectionType and nobody's been
> complaining about that. Besides, sequences don't necessarily even terminate.
>
> -Kevin Ballard
>
> On Wed, Dec 30, 2015, at 04:01 PM, Daniel Duan wrote:
>
> Users who don’t get the single-pass nature of SequenceType may expect a
> .last as well.
>
>
> Ah you're right, I was just looking at the unconstrained protocol. In any
> case, we could theoretically provide a .last, but I don't think that's
> useful enough on sequences to warrant inclusion. I know I've wanted .first
> many times and I've never wanted .last.
>
> Another motivation for adding this that I forgot to mention is that today
> the code `someCol.lazy.filter(pred).first` actually isn't lazy at all, it
> filters the entire collection and builds a new array (because SequenceType
> doesn't have .first so it resolves the .filter() to the eager version
> instead of the lazy version).
>
>
> Oh, that’s nasty.  I wonder if there’s something we can do with ambiguity
> to make the eager overload inaccessible in that context?  Would you mind
> opening a bug for this?
>
> Adding .first to SequenceType makes that expression actually do what the
> user intended (although my other proposal for SequenceType.find() provides
> a much better way to accomplish the same task).
>
> On Wed, Dec 30, 2015, at 04:40 PM, gs. wrote:
>
> I like this addition and I think that we should take care to document
> whether or not this mutates the sequence. I actually expect it to but maybe
> I am mistaken.
>
>
> (moving this back to the list)
>
> I considered documenting that, but none of the existing "destructive"
> methods on SequenceType document that. I think the assumption is that
> anything that has to inspect the contents of the sequence is obviously
> consuming the sequence to do that. In fact, the one method that doesn't
> consume anything (not counting generate() since any use of the generator is
> destructive), underestimateCount(), is explicitly documented as being
> non-destructive.
>
> Also, I couldn't think of a non-awkward way to say "this property
> partially consumes the sequence if it's a sequence that is destructively
> "consumed" by iteration". Especially because "partially consumed" isn't
> actually a property of sequences; it's explicitly documented that calling
> generate() a second time after any iteration is allowed to return a
> completely arbitrary sequence of elements from the second generator (for
> example, a generator that returns lines read from some stream might buffer
> more data internally and therefore constructing a second generator would
> possibly skip data that was never returned from the first generator).
>
> -Kevin Ballard
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160101/67199a1e/attachment.html>