Skip to content

Conversation

@DougGregor
Copy link
Member

The ContiguousBytes protocol covers various types that can provide unsafe access to their stored bytes. Generalize the ContiguousBytes protocol by making it non-copyable and non-escapable, so that the Span family of types and InlineArray can conform to it.

Fixes rdar://163716671.

The ContiguousBytes protocol covers various types that can provide
unsafe access to their stored bytes. Generalize the ContiguousBytes
protocol by making it non-copyable and non-escapable, so that the Span
family of types and InlineArray can conform to it.

Fixes rdar://163716671.
@DougGregor
Copy link
Member Author

@swift-ci please test

@parkera parkera requested a review from jmschonfeld October 30, 2025 17:51

//===--- ContiguousBytes --------------------------------------------------===//

#if compiler(>=6.2)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Foundation only compiles with the most recent released compiler + main, so I don't think this check is required.


//===--- Span Conformances -----------------------------------------===//

@available(FoundationPreview 6.3, *)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a public conformance, right? We would need an API review.

acceptContiguousBytes(bytes.span.bytes)

let ms = bytes.mutableSpan
acceptContiguousBytes(ms.bytes)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
acceptContiguousBytes(ms.bytes)
acceptContiguousBytes(ms.mutableBytes)

/// Indicates that the conforming type is a contiguous collection of raw bytes
/// whose underlying storage is directly accessible by withUnsafeBytes.
@available(macOS 10.10, iOS 8.0, watchOS 2.0, tvOS 9.0, *)
public protocol ContiguousBytes: ~Escapable, ~Copyable {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just confirming, are there any ABI implications on this change?

}

@available(FoundationPreview 6.3, *)
@available(macOS 26.0, iOS 26.0, tvOS 26.0, watchOS 26.0, visionOS 26.0, *)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The double availability attribute seems a bit suspicious here - each declaration should only have a single availability. Is the problem here the macOS back deployment build of the package? If so, we'll need to create a new availability macro (something like FoundationInlineArray) that maps to macOS 26-aligned in the package manifest / CMake files

private struct ContiguousBytesTests {
@available(macOS 26.0, iOS 26.0, tvOS 26.0, watchOS 26.0, visionOS 26.0, *)
@Test func span() throws {
if #available(FoundationPreview 6.3, *) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the function is already annotated as only available on macOS 26+, I don't think we need this #available check here. In the end what we probably want is for this function to be annotated as @available(FoundationInlineArray 6.3, *)

/// the same buffer pointer will be passed in every time.
/// - warning: The buffer argument to the body should not be stored or used
/// outside of the lifetime of the call to the closure.
func withUnsafeBytes<R>(_ body: (UnsafeRawBufferPointer) throws -> R) rethrows -> R
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's probably still work to be done on this protocol to update it (it doesn't allow for producing a span, it hasn't adopted typed throws, etc.) but this seems like a reasonable step in a good direction that we can do without fully fleshing out those changes at the moment if we want to update this incrementally

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants