How does the standard library get audited to be as good as Algorithms, Collections, etc.?

Lantua · December 22, 2021, 6:51pm

FWIW, the full Swift Evolution process is documented here: swift-evolution/process.md at main · apple/swift-evolution · GitHub.

Saklad5 · December 24, 2021, 7:35pm

@anon9791410 Funnily enough, the standard library actually has an implementation of that already. Sort of.

github.com

apple/swift/blob/59559ca0ce668b0240bcb2a91f874922a8eba2d7/stdlib/public/core/Sequence.swift#L56-L101


      
          /// Using Iterators Directly
          /// ========================
          ///
          /// You rarely need to use iterators directly, because a `for`-`in` loop is the
          /// more idiomatic approach to traversing a sequence in Swift. Some
          /// algorithms, however, may call for direct iterator use.
          ///
          /// One example is the `reduce1(_:)` method. Similar to the `reduce(_:_:)`
          /// method defined in the standard library, which takes an initial value and a
          /// combining closure, `reduce1(_:)` uses the first element of the sequence as
          /// the initial value.
          ///
          /// Here's an implementation of the `reduce1(_:)` method. The sequence's
          /// iterator is used directly to retrieve the initial value before looping
          /// over the rest of the sequence.
          ///
          ///     extension Sequence {
          ///         func reduce1(
          ///             _ nextPartialResult: (Element, Element) -> Element
          ///         ) -> Element?

This file has been truncated. show original

Ben_Cohen · December 24, 2021, 10:15pm

This post, especially the title, is phrased as if it is a given that the version of reduce you propose is so "obviously" necessary that it is essentially a bug that it doesn't already exist.

But in practice, reductions and reduce are not the same. reductions returns an array, so an overload that returns an empty array is a natural step with little downside. Whereas reduce would have a different return type – an optional Element? instead of a non-optional T. Maybe that's fine, maybe it's added complexity that weighs against it, but it's a significant difference.

This variant of reduce has already been pitched in the past and the response was mixed. Several posts questioned the general utility for this addition. So it's not really appropriate to frame this as if its absence means something is wrong.

I suggest editing the title to not presuppose so much. But to answer a possible rephrasing of the question: "How can the standard library adopt some good idioms from the algorithms package?" the answer is to pitch them, see if they have broad support, and if so we can run a review.