DoubleWidth Use in Other Projects

I've been building a series of FNV-1 hashers with different digest sizes. I used the DoubleWidth code in _TestSupport to get unsigned integers more than 64 bits wide. Since it isn't part of the public API for Swift Numerics yet, I'm curious about the ethics/licensing implications of including that code in a public open-source project without an explicit dependency. Is this something I should expose as public with warnings or just not make it public at all?

I can't offer any legal advice, but I think the license does allow redistribution (without modifications).

You've retained the copyright notice, and your README file makes it clear that the file originates from Swift Numerics.

Your code would be easier to read (and update) with type aliases:

public typealias FNVDigest128 = DoubleWidth<UInt64> // FIXME: Swift.UInt128

public typealias FNVDigest1024 = DoubleWidth<DoubleWidth<DoubleWidth<DoubleWidth<UInt64>>>>
  • Swift Numerics might introduce an alternative with better performance.
  • The standard library might introduce Int128 and UInt128 types.

Your extension Float16: FNVHashable might be incorrect.

The standard library only excludes Intel-based Macs:

#if !((os(macOS) || targetEnvironment(macCatalyst)) && arch(x86_64))
@available(macOS 11.0, iOS 14.0, tvOS 14.0, watchOS 7.0, *)

Swift Numerics also uses #if swift(>=5.4) but should it be using #if compiler(>=5.4) instead?

For the Hashable.hash(into:) method of floating-point types, the standard library:

  • combines the bitPattern rather than using withUnsafeBytes(of:)
  • uses the same hash value for ±0.0 to match equality.

Thanks for the quick code review, I appreciate it!

Your code would be easier to read (and update) with type aliases

I originally didn't want to use aliases to make it as clear as possible that the larger digests rely on nested DoubleWidths and this is not recommended. But it's true I might as well put that in docs and make the code easier to work with.

Your extension Float16: FNVHashable might be incorrect

Thanks for the insight. I included this a while back and satisfied the compiler at the time, but I never looked into the specific availability of Float16, I'll mirror it.

For the Hashable.hash(into:) method of floating-point types

I appreciate you linking to the actual source, that makes sense. I also see some Float80 related stuff in there, will be worth a look for sure.

1 Like

This is really important; without doing this, you do not have a valid Hashable conformance.