Contribution criteria clarification

I just read the blog post of the initial release of the Algorithms package and I'm kind of confused about this section:

The immediate focus of the package is to incubate a pragmatic set of algorithms generalized over the Sequence and Collection family of protocols for eventual inclusion in the Swift standard library—the kind of functionality you might find in the Python itertools module or the C++ algorithms library.

There are many interesting and useful abstractions that don’t meet this criteria. For example:

  • Currency types (e.g. Result ) and data structures (e.g. OrderedDictionary )
  • One-off conveniences (e.g. Dictionary.subscript(key:default:) ) that don’t generalize over Sequence or Collection
  • Classic algorithms (e.g. quicksort, merge sort, heapsort, insertion sort, etc.) with more pragmatic alternatives
  • Algorithms over non-linear data structures
  1. Why are those "interesting and useful abstractions" considered to not be included in the Algorithms package?
  2. If not here, where else should they be included, directly into Swift or is there any other package planned for them with a different name?
  3. Or did I misunderstand this and you just mean you don't want to include those "interesting and useful abstractions" right now, because the "immediate focus" is different, but we could add them later? When would that "later" be?

I really got excited when I heard about this as I thought I could finally add some of the helpers from my Swift Standard Library extension library HandySwift directly into this package, like a SortedArray type. But seeing OrderedDictionary explicitly stated as a "doesn't meet criteria" example really got me confused. I'd like to at least understand the rationale here ...

1 Like

It’s a good question!

In the blog post we wrote:

Packages like Swift Algorithms (and Swift Numerics) complement the Swift Evolution process by providing a means to:

  • Engage the community earlier in the development process
  • Channel contributions towards active areas of focus
  • Solicit feedback informed by real-world usage
  • Coherently tackle large tracts of missing functionality

If I understand correctly, your question is “Why limit this to just algorithms? These benefits would also apply to all kinds of other contributions!”

One of the reason is that we think algorithms, numerics, and data structures require different domain expertise, and we don’t just think of these as packages, we also think of them as watering holes for people to gather and for Swift sub-communities to form around. As an example, collections require devoting a significant amount of thought to ABI considerations.

Another important point from the blog post is that many contributions should go straight to Swift Evolution. It’s just that as we started to build out new families of related algorithms, we noticed a densely connected graph of API naming and design considerations. We felt the most effective way to tackle this would be to iteratively exploring the problem space in a package.

3 Likes

No, I think that's a misunderstanding. I did not ask to add non-algorithms to the Algorithms package, that would obviously be incorrect. To me the examples included things though which sound very algorithmic to me, including the OrderedDictionary and also the classic sorting algorithms.

But from your answer it is now clearer to me how it was meant: Basically you answered my second question with "Those ordered data structures belong to a package named DataStructures" instead of the Algorithms package. And I also now understand what is meant with "practical" approaches instead of classic algorithms for sorting. You mean we should not include any algorithms which have no practical usage because there's more efficient alternatives. So algorithms that only serve an educational purpose should not be included, what I can understand.

In other words, if I had any algorithms that would not be considered a new data structure, I could add that to the algorithms package and that there might probably be an official DataStructure package in the future.

Ya!

Exactly!

Terms of Service

Privacy Policy

Cookie Policy