-
Notifications
You must be signed in to change notification settings - Fork 721
Adding RawSpan support to writeBytes in ByteBuffer #3269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Motivation: With the new Swift version (6.2) we get access to spans for safely interacting with the contiguous memory owned by other types. Allow users write bytes to the ByteBuffer with RawSpans. Modifications: * ByteBuffer-core: Overload the setBytes, _setBytes, and _setBytesAssumingUnique BufferAccess to use RawSpan instead of UnsafeRawBufferPointer * ByteBuffer-aux: Overload the writeBytes to use RawSpan instead of UnsafeRawBuf ferPointer Result: Users can now write the contiguous memory of other types into ByteBuffer using the new RawSpan overloads, removing the need for unsafe pointer handling.
Lukasa
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shiny, this looks great. Thanks @yigityazicilar!
| @discardableResult | ||
| @inlinable | ||
| @available(macOS 26, iOS 26, tvOS 26, watchOS 26, visionOS 26, *) | ||
| public mutating func writeBytes(_ bytes: RawSpan) -> Int { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we mark this as consuming?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need: we don't consume it. We copy the bytes out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, and also Span is copyable, so consuming doesn't have much of a practical effect either. It can, in the best case, elide a copy of the Span object, but that's just two words so it's not really worth the hassle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah Span is Copyable so this might give the compiler a nudge to optimize it a bit better. At least that's what I was thinking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If anything, it should be borrowing, right? We're happy to just borrow this -- now as per @Lukasa's point: not much to win here of course.
| @discardableResult | ||
| @inlinable | ||
| @available(macOS 26, iOS 26, tvOS 26, watchOS 26, visionOS 26, *) | ||
| public mutating func setBytes(_ bytes: RawSpan, at index: Int) -> Int { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here?
Motivation:
With the new Swift version (6.2) we get access to spans for safely interacting with the contiguous memory owned by other types. Allow users write bytes to the ByteBuffer with RawSpans.
Modifications:
Result:
Users can now write the contiguous memory of other types into ByteBuffer using the new RawSpan overloads, removing the need for unsafe pointer handling.