# SE-0557: Add \`RawSpan\` primitive to \`Hasher\` **URL:** \ **Category:** Proposal Reviews\ **Created:** [October 12, 2026, 6:16pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025 "2026-10-12T18:16:25Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [October 12, 2026, 6:16pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/1 "2026-10-12T18:16:25Z")
Hi everyone. The review of [SE-0557, _Add `RawSpan` primitive to `Hasher`_](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0557-hasher-rawspan-primitive.md), 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](https://github.com/swiftlang/swift-evolution/blob/main/process.md). Thanks for taking the time to contribute to Swift's evolution! Joe Groff Review Manager ---
**Author:** ![KeithBauerANZ](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/keithbaueranz/32/27897_2.png) [@KeithBauerANZ](https://forums.swift.org/u/KeithBauerANZ)\ **Post date:** [October 12, 2026, 8:40pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/2 "2026-10-12T20:40:58Z")
[SE-0456](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0456-stdlib-span-properties.md) added this property to `Span`: ```swift 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](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0525-rawspan-safe-loading-api.md)'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`? ---
**Author:** ![glessard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/glessard/32/409_2.png) [@glessard](https://forums.swift.org/u/glessard)\ **Post date:** [October 12, 2026, 8:54pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/3 "2026-10-12T20:54:00Z")
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)](https://forums.swift.org/t/88498) , and it is still under serious consideration. ---
**Author:** ![Lancelotbronner](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lancelotbronner/32/22071_2.png) [@Lancelotbronner](https://forums.swift.org/u/Lancelotbronner)\ **Post date:** [October 13, 2026, 2:08pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/4 "2026-10-13T14:08:54Z")
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. ---
**Author:** ![Nobody1707](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nobody1707/32/2169_2.png) [@Nobody1707](https://forums.swift.org/u/Nobody1707)\ **Post date:** [October 13, 2026, 2:48pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/5 "2026-10-13T14:48:35Z")
Unless they're opaque structs, that seems like a bug. All plain C types should be `BitwiseCopyable`. ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [October 13, 2026, 3:38pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/6 "2026-10-13T15:38:33Z")
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. ---
**Author:** ![j-f1](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/j-f1/32/12287_2.png) [@j-f1](https://forums.swift.org/u/j-f1)\ **Post date:** [October 13, 2026, 4:26pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/7 "2026-10-13T16:26:10Z")
Which guidelines are you pulling from for that recommendation? I’d expect it to align with `append(_:)`/`append(contentsOf:)` ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [October 13, 2026, 4:39pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/8 "2026-10-13T16:39:03Z")
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.) ---
**Author:** ![Lancelotbronner](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lancelotbronner/32/22071_2.png) [@Lancelotbronner](https://forums.swift.org/u/Lancelotbronner)\ **Post date:** [October 13, 2026, 4:49pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/9 "2026-10-13T16:49:54Z")
> [@Nobody1707](#): > > Unless they're opaque structs, that seems like a bug. All plain C types should be `BitwiseCopyable`. I’ll report a bug then, and probably a feedback item! All structs in the macOS MachO module seem to not be BitwiseCopyable. ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [October 13, 2026, 5:29pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/10 "2026-10-13T17:29:54Z")
> [@grynspan](#): > > 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.) That's an affectation which organically arose, not a rule 🙂 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. ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [October 13, 2026, 6:03pm UTC](https://forums.swift.org/t/se-0557-add-rawspan-primitive-to-hasher/90025/11 "2026-10-13T18:03:01Z")
> [@xwu](#): > > That's an affectation which organically arose, not a rule 🙂 "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](https://www.swift.org/documentation/api-design-guidelines/#argument-labels): > **When the first argument forms part of a [prepositional phrase](https://en.wikipedia.org/wiki/Adpositional_phrase#Prepositional_phrases), give it an argument label**. The argument label should normally begin at the [preposition](https://en.wikipedia.org/wiki/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.