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

Evolution Discussion
1

For example, I noticed that Algorithms has this overload:

@inlinable
public func reductions(
  _ transform: (Element, Element) throws -> Element
) rethrows -> [Element] {
  var iterator = makeIterator()
  guard let initial = iterator.next() else { return [] }
  return try IteratorSequence(iterator).reductions(initial, transform)
}

I've been importing my own version of that, for reduce, for years. I don't want to do that; I want us all to have it, maintained to a high standard.

What should we do when these discrepancies crop up?

/// - Returns: `nil` If the sequence has no elements, instead of an "initial result".
@inlinable func reduce(
  _ nextPartialResult: (Element, Element) throws -> Element
) rethrows -> Element? {
  var iterator = makeIterator()
  return try iterator.next().map { first in
    try IteratorSequence(iterator).reduce(first, nextPartialResult)
  }
}
2

I’m not sure what you’re asking: those packages are supposed to be used by everyone. They’re effectively expansions of the standard library, and they actually get developed the same way.

You should be using those packages as casually as you do the standard library.

3

I can't speak as to the actual intent behind the API designers but I get the distinct impression that the various APIs are written and subdivided in a very deliberate way that reflects the dependencies as the toolchain is bootstrapped. The standard library has the most basic, fundamental functionality with a minimum of excess. Foundation is the first big library that provides a lot of API breadth and ergonomics on top of that. However, Algorithms depends on SPM, and SPM depends on Foundation. The Swift toolchain/SDK provides Foundation and SPM.

You could certainly put some functionality in Algorithms in the standard library, but the real question is why would you need or want to?

4

Source: https://www.swift.org/blog/swift-algorithms/

5 Likes
5

I don't see an answer to my question in that. Do you?

6

Sorry, what was the question?

1 Like
7

I see the answer. If something is good enough for Algorithms, it may make its way into the stdlib. Until it does, there's always Algorithms. If you had a different question, I'm with Lantua.

8

I think Jessy is asking for an overload of reduce which takes no initial value but gets it from the start of the sequence if not empty, else returns nil.

Unless I'm mistaken, that overload is neither found in the standard library nor in Algorithms.

2 Likes
9

Exactly. It seems like people didn't read my post, and are assuming that I'm asking for something that's literally in Algorithms, rather than what I'm actually asking about, which is parity.

I'm fine with the missing overloads being in Algorithms, but I'm not fine with [link back to OP].

10

There is one question mark in the title and one in the post. The second one follows a restated repetition as is standard.

1 Like
11

I'm sorry, but you're being obtuse. The question posed by the title of the post implies you're asking how a method that's already in Algorithms (or another similar package) gets moved to the standard library.

The question in the body of your post asks about a discrepancy where there is none. That your particular overload is not present is not a discrepancy.

So it's easy to understand why practically no one understood what you're actually asking.

16 Likes
12

I thought he was fairly clearly (if a bit vaguely) asking why the standard library is not up to the general level of quality (in terms of convenient affordances like hisreduce example) of other official packages like Algorithms. (I am not endorsing his claim, just restating it.)

The question perhaps seems a bit strange since the reduce example itself isn’t even part of Algorithms.

I would have thought the answer to how to address functionality you believe to be missing and worth adding was to propose adding it, but I have no direct experience with proposals to add overloads or other functionality to the standard library, so maybe I’m missing something.

13

I said that, but he said that's not what he meant.

1 Like
14

@anon9791410 Are you asking how to contribute to Swift Algorithms?

15

10 hearts is really very much too much for this post. I don't appreciate all of the answers without actually reading my post; it's too much noise and we should all delete our posts after someone provides an answer.

I don't understand what you all don't understand so I will say what I think is too much, and you can pick from it what you need, to get me an answer if you have it:

  1. reductions has more overloads than reduce.
  2. reductions and reduce are similar. I don't know what this is called. "Sibling method"?
  3. This is an example of Algorithms having a larger level of good than the standard library.
  4. Algorithms should not be better than the standard library, and vice versa. (See OrderedDictionary for appropriate symmetry in action, via an unfortunate bunch of code copying from Dictionary.)

What do human beings do in order to fix this and all other similar problems?

1 Like
16

The relationship between Swift Algorithms and the standard library has already been explained.

Not only isn’t what you describe a problem, it’s deliberate that Algorithms will offer more facilities than the standard library, and only the ones that are most proven out may eventually make their way into the standard library. This does not make one “more good,” and there is nothing to fix since it is the intended state of things.

I don’t think any more conversation on this is productive.

8 Likes
17

This is inevitable (at least when you define "goodness" as "having all the features I want"). The packages that the standard library team produces don't have the burden of the standard library of trying to stay compact, because people explicitly get to choose what packages to use and modules to import. So the barrier of "is this feature compelling enough to include" is much lower. Over time, the most generally useful features will migrate into the standard library, but the packages will always be "in the lead" for this reason.

And because--by definition--you're more interested than the average Swift programmer in the features of a package that you choose to import and use, there will always be some package features that are a major convenience for you but don't quite meet the bar of general usefulness for inclusion in the standard library.

And that's OK! We don't want to dump all possible functionality into a single module that's automatically imported. There's lots of good stuff that we can provide, but shouldn't be in everyone's namespace all the time.

26 Likes
18

This is a great post. Thank you.

Trouble is, everybody needs that reduce overload.

2 Likes
19

It's not an unreasonable request. I'll be happy to help you walk a proposal through evolution if you'd like.

7 Likes
20

Need is a strong word, especially considering that extensions cannot be removed, only added.

Anyway, the change you want to make is defaulting initialResult to nil when Result is Optional?

Personally, I don’t really see the utility. Could you give some examples of when you use that? I can’t actually think of a time I don’t want to start with an identity element.

1 Like