The UUID and NSUUID types have long been slightly out of compliance with RFC 4122, which specifies that the string representation of UUIDs should be in lower case. (I believe NSUUID has always used upper case in part because it predates that RFC?)

The use of upper case creates problems when interacting with external APIs that generate and send UUID values in their responses (in lowercase, as per the RFC) but expect exact string matches for these values in subsequent requests: a round-trip through a Swift using UUID will result in the value being transformed into an upper case spelling.

In my own projects, I've taken to using a LowercaseUUID type which wraps a UUID and overrides uuidString, description, and encode(to:) to apply a .lowercased() transformation in each case. However, it would be preferable if there was a way to specify this behaviour directly within Foundation, and it seems to me that this project presents an opportunity add this or alter the default.

Date’s description function uses a fixed size buffer (26 bytes, see here). This buffer is given to strftime.

Both, dates before “-999-01-01 00:00:00 +0000” and starting at “10000-01-01 00:00:00 +0000”, will require 27 bytes or more (including null byte at the end).

The return value of this function is checked by guard strftime(…) >= 0 (see). While most library functions in C return a negative value on failure, strftime returns 0 if the buffer is not big enough to hold the formatted date. Thus this guard never executes.

The buffer in this case is not guaranteed to contain a ending null byte, as the man page states: “Otherwise, 0 shall be returned and the contents of the array are unspecified.” (Highlighting mine)

The undefined content (worst case: 26 bytes forming valid UTF-8, e.g. 26 spaces) is then given to String(validatingUTF8:) which probably will (in the worst case) run behind the end of the buffer, resulting in a crash.

I suggest to either replace the call to strftime by a better API or change the buffer size to be big enough to hold any description of any point in time that Date might represent. In addition to that, the guard should be changed to guard strftime(…) >= 25 given that is the smallest valid size.

test cases:

Date(timeIntervalSinceReferenceDate: TimeInterval(-63145526400)).description == "0000-01-01 00:00:00 +0000"
Date(timeIntervalSinceReferenceDate: TimeInterval(-4200000000000)).description == "-131090-12-30 21:20:00 +0000"
Date(timeIntervalSinceReferenceDate: TimeInterval(4200000000000)).description == "15310-04-10 02:40:00 +0000"

Umbrella issue tracking UUID

Umbrella issue to keep track of JSONEncoder, JSONDecoder, and friends.

Umbrella issue to track CocoaError.

Umbrella issue tracking Locale.

jobs:
  windows:
    runs-on: windows-latest
    steps:
      - uses: compnerd/gha-setup-swift@main
        with:
          branch: swift-5.5-release
          tag: 5.5-RELEASE
      - uses: actions/checkout@v2
      - run: swift test

Issue Description:

The following code crashes on Windows.

func testURLs() throws {
    for _ in 0..<20 {
        if let url = URL(string: "https://raw.githubusercontent.com/jmespath/jmespath.test/master/tests/filters.json") {
            _ = try Data(contentsOf: url)
        }
    }
}

Umbrella issue tracking Date

After we have Locale and the FormatStyle APIs (#42), implement ISO8601 for JSON.

If using FoundationPreview on Darwin and the file imports something which transitively imports Foundation (notably XCTest), we wind up with ambiguous definitions of Foundation's API. Some of this can be worked around with a typealias (see https://github.com/apple/swift-foundation/blob/main/Sources/TestSupport/TestSupport.swift), but other times we have to fully qualify the name.

(content deleted)

Locale's canonicalIdentifier depends on a table in CoreFoundation: https://github.com/apple/swift-corelibs-foundation/blob/main/CoreFoundation/Locale.subproj/CFLocaleIdentifier.c

Without support for constant collections in Swift, a naive port of this would result in a pretty large allocation and memory usage regression. We may be able to take advantage of some of ICU's support for canonicalization, but we will need to verify compatibility with the existing implementation. Some callers may be expecting some of the legacy conversions to continue to work.

Description

Bundle was Sendable in Swift 5.7.x. Starting with Xcode 14.3 beta 1 and Swift 5.8 I see that that extension has been marked unavailable:

@available(*, unavailable)
extension Bundle : @unchecked Sendable {}

Was that intended?

Environment

• Swift: swift-driver version: 1.75.1 Apple Swift version 5.8 (swiftlang-5.8.0.117.11 clang-1403.0.22.8.60)
• Xcode: 14.3 (14E5197f)
• Deployment target: iOS 12.0

Umbrella issue tracking AttributedString

Sub issue under #220 tracking Data Base64 encode/decode.

In the Swift 6 timeframe, we should see if we can stop including swift-corelibs-foundation in the Linux toolchain completely, and transition clients to the package.

It's unclear what kind of knock-on effects this may have on existing clients which import Foundation, and Swift package manifests which have an import Foundation themselves for usage of the Bundle type.

Umbrella issue to track Decimal.

Decimal is used by a few core types in Essentials, but it probably also needs some updates to be a better citizen in Swift. In ObjC it is a C struct, so it would be difficult to share the sources exactly.

Umbrella issue to track all FormatStyle and ParseStrategys.

Description

ISO8601 standard allows representing years before 0000 or after 9999 using a "-" or "+" sign as prefix to four digits (±YYYYY). Apparently, there is no option in Swift's current ISO8601DateFormatter that enables such formatting, which causes errors in systems where there is such an agreement with client and server to follow that standard option.

Steps to reproduce

import Foundation

let date = Date(timeIntervalSince1970: 253402300800) // January 1, 10000
let formatter = ISO8601DateFormatter()

let formattedDateString = formatter.string(from: date) // "10000-01-01T00:00:00Z"

print(formattedDateString)

Expected behavior

Expected formattedDateString to be "+10000-01-01T00:00:00Z" (either with the default ISO8601DateFormatter implementation or with an option provided within the ISO8601DateFormatter.Options and setting it on formatter instance explicitly) in order to be compliant with ISO8601.

Environment

• Swift compiler version info
  • swift-driver version: 1.62.8 Apple Swift version 5.7 (swiftlang-5.7.0.127.4 clang-1400.0.29.50)
  • Target: arm64-apple-macosx12.0

We are disabling this test with #147 . Look into why it's failing on Linux.

Umbrella issue tracking Calendar

I'm using Swift Language on a Linux system

My OS Distro is Fedora 37 on an ARM64 CPU
I'm using Swift version 5.7.3 (swift-5.7.3-RELEASE) from the Fedora repos

I'm using GNOME desktop and have set my user session language to spanish, and my region to Mexico

When I run the locale command on a terminal, I get this output:

LANG=es_ES.UTF-8
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC=es_MX.UTF-8
LC_TIME=es_MX.UTF-8
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY=es_MX.UTF-8
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER=es_MX.UTF-8
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT=es_MX.UTF-8
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=

But when I reference Locale.current, either on a compiled program, or from the Swift REPL, I get a "en_US" Locale. For example, if I run print (Locale.current.identifier) on the REPL, i get:

en_US

I think the expected behavior is that Locale.current returns the same locale from my user settings. Or am I missing something?

The swift stdlib deprecated _isContiguousASCII, but Foundation depends on it for String extensions.

Is there a better entry point to use, or should we remove the deprecation from stdlib?

/swift-foundation/Sources/FoundationEssentials/String/String+Essentials.swift:109:70: warning: '_isContiguousASCII' is deprecated
            if encoding == .utf8 || (encoding == .ascii && str._guts._isContiguousASCII) {

Currently, Date.description contains a large stack allocation of 128 bytes:

This allocation is almost certainly larger than necessary, but the behaviour of strftime, the C-library call being wrapped here, should be explored on Windows before we shrink the allocation size.

ICUNumberFormatter doesn't support UInt64 number formatting. Integers not representable by Int64 are clamped as per documentation.

Under current implementation, however, if a BinaryInteger cannot be converted into Int64, IntegerFormatStyle will first attempt to convert the integer into Decimal (represented by Double) before falling back to clamping. This may result in inconsistent formatting behavior.

One edge case is 9223372036854775808 (Int64.max + 1). This integer can be converted to a floating-point value (9.223372036854776E+18), which will then be formatted into "9" instead of the the clamped number of 9,223,372,036,854,775,807 (Int64.max).

Should we drop the Decimal conversion in IntegerFormatStyle?

• IntegerFormatStyle: Lines 221-222
• IntegerFormatStyle.Percent: Lines 253-254
• IntegerFormatStyle.Currency: Lines 285-286
• AttributedString: Lines 512-513

Personally, I would prefer to drop the Int64 clamping as well and fall back to the Swift Standard Library's LosslessStringConvertible: String(value). This will allow us to preserve the correct numeric value albeit incorrect format. Ideally, we should have a proper implementation for UInt64 number formatting.

Until we have full parsing of URL strings ported, provide a URL implementation that works with at least file schemes. This should unblock usage of Data and a few other key cases.

Attachment: Download

Issue Description:

I was trying to user CharacterSet to check if a user input string contains any non decimal digit characters. I use CharacterSet.decimalDigits and take the intersection of that with the user input. If this intersection is empty, it presumably means the user hasn't entered valid input. Yet the intersection is not empty.

let digits = CharacterSet.decimalDigits  
let letters = CharacterSet(charactersIn: "abcd") // never prints

let intersection = digits.intersection(letters)  
for c in "abcd".characters {  
  if intersection.contains(UnicodeScalar(String(c))!) {  
    print("contains \(c)") // never prints  
  }  
}

for i in 0...9 {  
  if intersection.contains(UnicodeScalar(String(i))!) {  
    print("contains \(i)")  
  }  
}

print("intersection is empty: (intersection.isEmpty)") // prints false

I even tried looping over all unicode scalars to test for membership, and that doesn't print anything.

for i in 0x0000...0xFFFF {  
  guard let c = UnicodeScalar(i) else {  
    continue  
  }  
  if intersection.contains(c) {  
    print("contains \(c)")  
  }  
}

Why is the set non empty?

Note: using let digits = CharacterSet(charactersIn: "1234567890") works as expected. I know that the decimalDigits contains more than just 0-9, but the intersection should still be empty.

Umbrella issue to track URL.

I know FormatStyle in "classic" Foundation (what do we call the other Foundation?) is Codable but it's unclear exactly why it needs to be. The Codable requirement can get in the way of implementing our own FormatStyles that use non-codable types - in particular closures.

Unless there's a compelling reason for swift-foundation's FormatStyle to be codable (quick scan through code didn't find anything) other than "it's Codable in Foundation" might it not be a good idea to remove the requirement?

Sometimes, I get a design that requires me to format a date interval for a week in such a way that does not include the day of the next week. There have been multiple times where I have had to manually make this calculation. As far as I can tell, there is no API to simplify formatting a date interval in this manner. What follows is a case for an API on Calendar to make this calculation more idiot-proof.

Consider a UI listing "to dos" between the start of this week but before the start of the next. I would like to have a heading that reads "Monday, 22 May, 2023 - Sunday, 28 May, 2023". But if I format the date interval for the week of year as I get it from Calendar now, I'd get "Monday, 22 May, 2023 - Monday, 29 May, 2023", which makes me think I have an extra day to do things in. To work around this, I can compute different dates, writing:

let date = /* some moment during some week */
let weekOfYearInterval = calendar.dateInterval(of: .weekOfYear, for: date)
let lastSecondOfLastWeekday = calendar.date(byAdding: .second, value: -1, to: date) ?? date // not sure what to coalesce here
let dateIntervalToFormat = DateInterval(start: weekOfYearInterval.start, end: lastSecondOfLastWeekday)

But I do not know if dateIntervalToFormat was calculated correctly. What tricky edge case awaits my users and I after I ship? Perhaps it's good but I'm not a calendar expert. From what little I know, I think any moment matching this predicate will suffice:
moment >= (the start of the day before the start of the next week) && moment < (start of the next week)
...but I am aware that I can also be a clueless idiot.

Formatting these intervals could be more convenient. Some ways they could be more convenient include:

• a Calendar API for calculating "some moment in a second/minute/hour/day/month/year before/after some date"
• a property on the formatter that treats the date interval as an inequality, rendering the end date to at some moment before.

The last option doesn't strike me as particularly good because it could create complexity in other formatting cases. Perhaps I lack imagination. So, if I could wish upon a star, a Calendar API for the first option could be:

func dateInterval(of component: Calendar.Component, direction: Calendar.SearchDirection, relativeTo date: Date) -> DateInterval

Then I could write my code above as:

let date = /* some moment during some week */
let weekOfYearInterval = calendar.dateInterval(of: .weekOfYear, for: date)
let lastSecondOfLastWeekday = calendar.dateInterval(of: .second, direction: .backward, relativeTo: weekOfYearInterval.end)
let dateIntervalToFormat = DateInterval(start: weekOfYearInterval.start, end: lastSecondOfLastWeekday.start)

I do not think there could reasonably be an API on Calendar to simplify this code any further. For example, to get it to one line, I'd need something like this:

let date = /* some moment during some week */
let almostCompleteWeekOfYearInterval = calendar.dateInterval(of: .weekOfYear, for: date, endingAtLowerComponents: true, direction: .backwards)

...but oooof 🙈

I find it highly irritating, that even though the "quarter" date component is public and available, it is not implemented in Calendar. I think this is really not a good developer experience, either it should be implemented or removed from all date component APIs.

Umbrella issue for tracking moving Predicate to FoundationPreview

Description
This bug is related to nil object returned when formatting using number formatter. When we changed the device location to spain it returned all nil values and for other locations it returns the exact expected formatted number.

Steps to reproduce
To reproduce it you have to use the following code snippet
let formatter = NumberFormatter()
formatter.locale = Locale.current
formatter.numberStyle = .decimal
let number = formatter.number(from: amount)

Once you build the app change the device location and you will see that this function returns nil value. For example number = nil

Expected behavior
Once the code snippet is executed it should set number as formatted amount based on the formatter applied.

Environment

• Swift compiler version info swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100)
  Target: arm64-apple-macosx13.0
• Xcode version info 14.3 (14E222b)
• Deployment target: 11.0

Description
Decimal.FormatStyle does not always respect the locale's decimalSeparator, also, the same error occurs with FloatingPointFormatStyle

Steps to reproduce
1- Set the iPhone region to Germany.
2- Set the iPhone language to English (US).
3- Set the Number Format decimal separator to period instead of the default comma.

Expected behavior

    let number: Decimal = 1.5

    let newFormatter = Decimal.FormatStyle.number
    let newResult = number.formatted(newFormatter) // 1,5 ❌

    let oldFormatter = NumberFormatter()
    oldFormatter.numberStyle = .decimal

    let oldResult = oldFormatter.string(from: number as NSNumber)! // 1.5 ✅

Environment

• Swift version: 5.7
• Xcode version: 14.2
• Deployment target: iOS 16.3

Umbrella issue tracking TimeZone

Umbrella issue tracking Bundle.

Most of the code in this project predates SE-0333, and has had to use the assumingMemoryBound(to:) and bindMemory() functions to adapt raw memory buffers to C function calls. Since then, the withMemoryRebound function was added for raw memory buffers and pointers. In most cases, withMemoryRebound is the correct function to use, as it only changes the state of memory binding within its closure, reverting it afterwards.

Sub feature under #220 tracking Data IO related tasks (such as write(to:options:)

Umbrella issue tracking Data and friends

Tasks

• #221
• #222

The testAPIStatement test winds up using a Swift string processing symbol that is marked available as of 5.8 but is actually only available in 5.9.

Factor out the Markdown support in AttributedString (which relies on a customized version of libcmark) and bring it to the package.

Umbrella issue to track URLComponents.

Umbrella issue for CharacterSet and friends.

This one might be slightly more tricky because the original NSCharacterSet APIs are not exactly great in Swift. We might (should?) also take this chance to rethink about CharacterSet's API surface.

Hello. I tried to compile my new test project with swift-foundation. But in linker step it throws following errors:

#0 265.7 error: link command failed with exit code 1 (use -v to see invocation)
#0 265.7 /usr/bin/ld.gold: error: /usr/lib/swift_static/linux/libicui18nswift.a(decNumber.ao): multiple definition of 'uprv_decNumberClass(decNumber const*, decContext*)'
#0 265.7 /usr/bin/ld.gold: /build/.build/x86_64-unknown-linux-gnu/release/ICUI18N.build/decNumber.cpp.o: previous definition here
#0 265.7 clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

In my project I include swift-foundation using this code

#if canImport(FoundationEssentials)
import FoundationEssentials
import FoundationInternationalization
#else
import Foundation
#endif

What's wrong and how I can fix it?

It would be nice if Essentials could have some basic support for formatting well-known date types like ISO8601 without relying upon the entire data set of ICU.

Locale could be sunk into Essentials with support for only a "system" locale (en_US-POSIX). Following this, we would be able to bring over the FormatStyle and ParseStrategy protocols from Internationalization, which would then unblock a new API for JSONEncoder and JSONDecoder to use them instead of the classic Formatter for their own Date-parsing behaviors.

Human augmented reality

Description

testSettingLocale in DateAttributedFormatStyleTests fails as shown in the following image.

This is caused by the fact that the result of formatting the string deviates from the actual time by 9 hours.
I am running on a macOS system that is set to a time difference of 9 hours from en_US, and it seems odd that the 9-hour time difference appears even though the Locale is set to en_US in the code.

Is this a problem with Date.FormatStyle?
Is there any information I should look at to fix this issue?

Expected behavior

Successful testing in any execution environment

Environment

OS: macOS 13.3.1（Apple M1）
Swift: Swift 5.9
Xcode: Xcode 14.3 (14E222b)

The current implementation for Data(contentsOf:) is written in C/ObjC and needs to be ported to Swift.