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

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

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

10 Likes

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.
3 Likes

+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

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.

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

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

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

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

1 Like

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.

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.

I am a big +1 on this approach.

I think it works well for scalability and usability.

1 Like

+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.

Terms of Service

Privacy Policy

Cookie Policy