Swift 5.0.2 repairs Foundation behavior on Linux

Receiving an HTTP response and successfully completing an application request are different outcomes. A server can return a valid response that says access is unauthorized. Swift 5.0.2 repairs a Linux Foundation path that had treated such a response as a task error. That is one of several library fixes in the July 16 announcement, which identifies this as a Linux bug-fix release.

The announcement also records that the release was originally planned for mid-June and took longer while fixes were backported. The delay matters because a merged fix and an available toolchain are separate deliverables. Application developers consuming a release need the library implementation actually included in that release, regardless of whether corrected source already exists elsewhere.

I like Swift’s language model, but a service executes the libraries shipped with its toolchain. Correct source code cannot compensate for a platform implementation that crashes or reports the wrong outcome. These maintenance changes deserve attention on their own terms.

An unauthorized response is still a response

The URLSession correction concerns basic authentication when the implementation cannot construct a URLProtectionSpace. A missing WWW-Authenticate response header can produce that situation. The corrected behavior invokes the completion handler with the response received, instead of failing the task with an error.

That preserves information at the correct layer. A caller can inspect an HTTP status and decide whether to ask for credentials, show a permission failure, or apply a service-specific policy. Reporting only a task failure can hide the difference between an answer from the server and a failure to obtain an answer.

The pull request explains why the earlier implementation had become especially awkward. Failing the task removed it from the task registry. Continuing into completion handling attempted another removal and produced a fatal error. A prior correction returned after reporting failure, but that skipped the completion handler. The new change addresses the interpretation of the response itself.

This sequence illustrates why callback lifecycle and protocol semantics need to agree. Avoiding duplicate cleanup is necessary, but a request can still have the wrong observable behavior after that crash is removed. The caller expects the completion path appropriate to an HTTP response. Keeping that response available permits application code to distinguish authentication policy from transport failure.

Calendar crosses an implementation boundary

Another included fix addresses SR-10333, a crash while requesting weekday components from the current calendar. The change overrides _NSCopyOnWriteCalendar._cfObject to return its backing calendar created through CFCalendarCopyCurrent().

The affected expression is ordinary Foundation usage. It asks the current calendar to interpret a date, then selects the weekday component. Nothing about that request requires an application to manage the internal representation of a calendar. The fix belongs to the library boundary between its wrapper and the Core Foundation object underneath it.

Copy-on-write is useful only when the implementation preserves the expected object relationship. A wrapper may defer copying or redirect access to backing storage, but callers still require the correct calendar operations. This is one reason to separate the public value model from the machinery used to implement it. The API can be appropriate while a particular implementation path remains defective.

I regard this as a stronger reason to adopt the patch than a general description of stabilization. The release names a reproducible Foundation operation and includes the correction for it. Linux users with date-handling code can connect the changed implementation to a concrete capability their application requires.

Formatter configuration should describe the final settings

The release also includes a DateFormatter setting-order fix. Its description says that assigning dateStyle and timeStyle must not depend on the current locale setting. The defect made the order of configuring those properties consequential on Linux.

That is troublesome because configuration code normally communicates a desired final combination of settings. If assigning the locale before the styles produces a different result from assigning it afterward, a reader has to understand an additional temporal contract. Moving a property assignment during an otherwise harmless refactoring can then change formatting behavior.

The patch removes that dependency for the affected settings. It does not make calendar and locale choices interchangeable, and it does not imply that all formatter properties commute in every context. The useful claim is the specific one in the fix, which concerns the relationship between style assignments and the current locale.

These corrections belong to swift-corelibs-foundation. They should not be read as a list of defects shared by every Foundation implementation on every operating system. The Linux release groups them with other toolchain changes, but the component named in each fix determines what behavior changes. For applications sharing source across platforms, that component boundary explains how the same API can need a maintenance update on one platform without implying an identical defect elsewhere.