[swift-evolution] Proposal: Add SequenceType.first

Gwendal Roué gwendal.roue at gmail.com
Sat Jan 2 07:53:39 CST 2016

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.

> Le 2 janv. 2016 à 13:42, Brent Royal-Gordon via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list