SE-0557: Add `RawSpan` primitive to `Hasher`

Evolution Proposal Reviews
1

Hi everyone. The review of SE-0557, Add RawSpan primitive to Hasher, begins now and runs through October 20, 2026.

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 the forum messaging feature. When contacting the review manager directly, please keep the proposal link at the top of the message.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • 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?

More information about the Swift evolution process is available here.

Thanks for taking the time to contribute to Swift's evolution!

Joe Groff
Review Manager

16 Likes
[Pitch] Add RawSpan primitive to Hasher
2

SE-0456 added this property to Span:

extension Span where Element: BitwiseCopyable {
  /// Share the raw bytes of this `Span`'s elements
  var bytes: RawSpan { get }
}

note that BitwiseCopyable is not as strong as SE-0525's ConvertibleToBytes, and bytes may therefore provide access to uninitialized memory.

I think allowing a RawSpan to be hashed under that circumstance is a footgun.

Perhaps we should retcon SE-0456 to only offer bytes where Element: ConvertibleToBytes? Perhaps we should make this extension on Hasher accept Span where Element: ConvertibleToBytes rather than RawSpan?

2 Likes
3

We can't retcon SE-0456 quite this much, but we would like to fix the naming problems. I opened this pitch thread during the summer: [Pitch/Discussion] Rename symbols that have been audited as unsafe (or fix LLVM) , and it is still under serious consideration.

5 Likes
4

I’m using bytes and Span(_bytes:) a lot with C interop and even BitwiseCopyable is sometimes too strong as some C structs for some reason don’t get the conformance.

5

Unless they're opaque structs, that seems like a bug. All plain C types should be BitwiseCopyable.

1 Like
6

I'd think the name should be combineBytes(_:) per Swift naming guidelines. I know the existing API is combine(bytes:), but we could rename it easily enough.

Anyway, ship it.

1 Like
7

Which guidelines are you pulling from for that recommendation? I’d expect it to align with append(_:)/append(contentsOf:)

8

I think just combine(_:) could conflict with the existing function of the same name. But generally the argument labels to functions aren't supposed to be nouns or noun phrases, but rather adpositions or adpositional phrases.

(I'm not at my desk or I'd dig up a specific link.)

9

I’ll report a bug then, and probably a feedback item! All structs in the macOS MachO module seem to not be BitwiseCopyable.

10

That's an affectation which organically arose, not a rule :slight_smile:

The API naming guidelines have us promote words to the base name when they apply to all arguments; but insofar as they model doing so for the first or only argument, it's a bit of a hangover from the original days when the first argument couldn't be labeled.

11

"Rule" is certainly too strong a word. We can name things whatever we want to name them if it comes down to it. But I am referring to our documented naming guidelines here:

When the first argument forms part of a prepositional phrase, give it an argument label. The argument label should normally begin at the preposition, e.g. x.removeBoxes(havingLength: 12).
[...]
Otherwise, if the first argument forms part of a grammatical phrase, omit its label, appending any preceding words to the base name, e.g. x.addSubview(y)

I think those guidelines apply here. addSubview(_:) and combineBytes(_:) are grammatically equivalent. But! I don't feel so strongly about it that I want to have a grand debate over it; I'm happy with combine(bytes:) if the community is.

2 Likes