The best interface is no interface, isn’t it? Why should we absolutely add
methods with unclear meanings or behavior, when there are already perfectly
clear, if verbose, alternatives? seq.generate().next() may not be nice, but no
one can get fooled by it.
Maybe we should discuss use cases, instead of "completing" a standard lib that
did not ask anything. It never stops: shouldn’t we add isEmpty to SequenceType,
if first was added? With the same ambiguity in both meaning and behavior...
Indeed I agree that the buffered sequence is much more interesting, and that it
overlaps with the implicit enhancement request behind SequenceType.first. I
have one experience where I wanted to know whether a sequence was empty before
consuming it, and a standard buffered sequence would have been a much welcomed
tool.
Gwendal
> Le 2 janv. 2016 à 13:42, Brent Royal-Gordon via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
> May I suggest a simple solution?
>
> extension SequenceType {
> /// Returns one element from the beginning of the sequence, or
> `nil` if the sequence is empty.
> /// If `self` is a single-pass sequence, this may consume the
> element.
> func one() -> Generator.Element? {
> var generator = generate()
> return generator.next()
> }
> }
>
> This should probably be a method in the protocol, and CollectionType should
> have an override which calls `first`.
>
> The BufferedSequence stuff suggested elsewhere is probably useful too, and
> should be considered in addition to this, but I think this would cover the
> most common case.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
