SE-0264 (review #2) — Standard Library Preview Package

Evolution Proposal Reviews
1

The second review of SE-0264 — Standard Library Preview Package begins now and runs through December 10, 2019

This is a follow up to the previous review discussion after the proposal was returned for revision.

The proposal is written by @ben_cohen, @moiseev, and @nnnnnnnn.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (via email or direct message in the Swift forums).

What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.

When reviewing a proposal, here are some questions to consider:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Thanks,
Ted Kremenek
Review Manager

12 Likes
2

Here’s the diff of the proposal between October 18 and today.

10 Likes
3

It isn't stated as a goal of the proposal but would it be possible to officially, retroactively introduce several preview packages of past proposals?

This would allow to back port naturally things like:

  • Result
  • diffing API's
  • Identifiable
  • etc.
4 Likes
4

+1. I like the revision. This approach will work for a wider range of users which should help drive early adoption of standard library features, including during the pitch and review phases of SE.

4 Likes
5

Given the following, I don’t think it will really be all that helpful for backporting availability constrained APIs. (Which Result doesn’t suffer from anyway.)

In order to keep the size of the SwiftPreview package manageable, re-exported proposal packages will be removed from the bundling package in a version update 1 year after migration to the standard library.

Such an official shim package (or other shimming strategy) would certainly be useful, but I don’t think the preview package is the place for it.

6

In the prototype, what is the intended purpose of the SwiftPreviewTests.swift file?

7

Looking at the prototype, why is the package named swift-preview? Right now we kind of have an inconsistent mess:

Package Name Library Name
SwiftPM SwiftPM (or SwiftPM-auto)
SwiftSyntax SwiftSyntax
swift-format SwiftFormat
cmark cmark
llbuild llbuildSwift
(swift-preview) (SwiftPreview)

This will become more apparent when SE‐0226 comes to fruition. (And the PRs are rolling in as we speak! :tada:) From its proposal (emphasis added):

To achieve this, the package manager needs to associate the product dependencies with the packages which provide those products without cloning them. We propose to make the package name parameter in the product dependency declaration non-optional. This is necessary because if the package name is not specified, the package manager is forced to resolve all package dependencies just to figure out the packages for each of the product dependency. SwiftPM will retain support for the byName declaration for products that are named after the package name. This provides a shorthand for the common case of small packages that vend just one product.

extension Target.Dependency {
    static func product(name: String, package: String) -> Target.Dependency
}
2 Likes
8

Nice catch! From that proposal:

In many cases, the package name and the last path component its URL are the same. Package name can be omitted for such dependencies.

That certainly indicates that the best practice will be to have the repo name match the SwiftPreview package name. I’ll make the requisite changes.

1 Like
9

But you would still be able to import the individual package.

1 Like
10

I don’t contest that such official backports would be useful. I just see their purpose as distinct from previews. That not only affects how long you plan to maintain them, it also affects the design in some ways. For example, on platforms not yet declared stable, a backfill would want to hide everything behind #if !os(Linux), etc, so that the standard library always takes over. But that would defeat the purpose of a preview package.

11

That seems like an assertion, but perhaps I don't understand your point. When packages from the preview package start shipping in the standard library then they become de facto backfill packages. So any concerns that apply to “retrospective preview packages”, i.e. things that probably would have been in the preview package had it existed, seem to apply to this proposal. I'm not necessarily supporting the idea, and I don't personally particularly care about backfilling either way, but I don't understand your arguments against it.

12

I am a big +1 on this approach.

I think it works well for scalability and usability.

1 Like
13

+1 for the proposal. I did a quick read and I do feel that the problem is worth solving. I think the proposal would help with quick adoption of new features.

Versioning gave me mixed feelings first, but after I though about it more I do agree that it will be a good way to handle it.

14

@tkremenek has the core team decided on this proposal or was it forgotten?

15

The core team has discussed this. There were some details I was figuring out related to the packages themselves. The core team will circle back on this within a couple days.

5 Likes
16

Proposal Accepted

The proposal has been accepted. The Core Team strongly believes that vending upcoming changes to the Standard Library via "preview packages" distributed using the Swift Package Manager could be a powerful vehicle to get additional signal on the quality of proposed changes to the Standard Library.

The Core Team was satisfied with the dual model of having an umbrella package that users can use to install all available APIs available as preview package, as well as individual packages that correspond to specific evolution proposals.

Each preview package will be housed in a separate repository in the apple organization on GitHub, sitting as peers to the other repositories part of the Swift project.

Here is the module name and repository mapping that the Core Team settled on:

Module Name Repository
StandardLibraryPreview swift-standard-library-preview
SE<number>_<shortname> swift-se<number>-<shortname>

Where <number> would be the 4-digit SE number, starting with 0 for proposals less than 1000, and <shortname> would be something short like "RangeSet" that is a pithy highlight of what that package covers.

Some examples

Module names

import StandardLibraryPreview
import SE0270_RangeSet
import SE0261_Identifiable
import SE0251_SIMD
import SE0235_Result

Repository names

  • swift-standard-library-preview
  • swift-se0270-rangeset
  • swift-se0261-identifiable
  • swift-se0251-simd
  • swift-se0235-result

Next steps

Thank you to everyone who participated in this review. The next steps are to create the initial repositories for the preview packages, as well as update Swift.org with information about the preview packages and their use. An announcement will be made when these changes have been made and the preview packages are available.

31 Likes
17

@tkremenek Great news. There are a few that I would like to clarify.

  • Would it make sense to introduce some of the past propsed API's as standalone packages which are now part of ABI stable stdlib binaries only?

  • For example as you already mentioned swift-se0235-result, swift-se0261-identifiable and potentially swift-se0240-diffing?

  • Does it make sense to handle some of the packages in a way like Swift Crypto is handled, which will re-import the framework if it's provided by the OS?

1 Like
18

Any particular reason for stipulating a fixed-width format for the number?

19

Just so that the order more nicely in a listing, and that they match how SE proposals are typically presented during proposal reviews, etc.

1 Like
20

In this case, the framework is the Standard Library, which is always imported.

1 Like