# Status check: Int128 & UInt128 **URL:** \ **Category:** Discussion\ **Tags:** bigint, int128, uint128\ **Created:** [October 5, 2023, 7:02pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694 "2023-10-05T19:02:26Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![wadetregaskis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wadetregaskis/32/8494_2.png) [@wadetregaskis](https://forums.swift.org/u/wadetregaskis)\ **Post date:** [October 5, 2023, 7:02pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/1 "2023-10-05T19:02:26Z")
[The Swift standard library actually contains Int128 & UInt128](https://github.com/apple/swift/blob/d58943a5088c53cf3c0acd8b18d0ca7053594225/stdlib/public/core/Int128.swift.gyb), they're just not exposed as public API. [They were added](https://github.com/apple/swift/commit/e675b310f89bb9fdfe6e139bdece3dcd28ad636f) as a prerequisite for [SE-0329: Clock, Instant, and Duration](https://github.com/apple/swift-evolution/blob/main/proposals/0329-clock-instant-duration.md). Their conspicuous absence from the public API was even raised during [that proposal's [third] review](https://forums.swift.org/t/se-0329-third-review-clock-instant-and-duration/54727) but [deferred as out of scope](https://forums.swift.org/t/se-0329-third-review-clock-instant-and-duration/54727/52). And there's been [some](https://forums.swift.org/t/128-bit-operations-in-swift/21639) [requests](https://forums.swift.org/t/arbitrary-sized-integers/2975) for them for many years, going back to [before these forums even existed](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018957.html). [swift-numerics](https://github.com/apple/swift-numerics/tree/182c9b246bf8523ec3f5ccb95815acdd9edeb714) has (essentially) [its own re-implementation of 128-bit integers](https://github.com/apple/swift-numerics/blob/182c9b246bf8523ec3f5ccb95815acdd9edeb714/Sources/_TestSupport/DoubleWidth.swift), and now [Foundation is considering adding their own too](https://github.com/apple/swift-foundation/pull/262#discussion_r1346449337). Not to mention the [various](https://github.com/spevans/swift-integer128) [3rd](https://github.com/oscbyspro/AwesomeNumbersKit/blob/fe348ee0c9d3f9a3fa53302b2cda61a596070621/Sources/ANKFullWidthKit/ANKFullWidth.swift#L207) [party](https://github.com/oscbyspro/Numberick/blob/1081daaba593cd71deb3805121574d5629968d1b/Sources/NBKDoubleWidthKit/NBKDoubleWidth.swift#L238) [packages](https://github.com/mgriebling/UInt128), and [the numerous private reimplementations of these types in other Swift libraries and programs](https://github.com/search?q=lang%3Aswift+int128&type=code). It seems a bit silly to copy-paste-proliferate such a fundamental numeric type, when it's already _in_ the standard library, it just needs to be released. I suspect it's already the goal to do that, though, so I hope the question is merely: ETA? 🙂 ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 5, 2023, 7:06pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/2 "2023-10-05T19:06:26Z")
To be clear: Foundation is not considering adding their own. They're recommending using the existing DoubleWidth test support from Numerics for testing purposes (at my urging). We will pitch Int128 for the stdlib soon, but even once it's available, Foundation and Numerics should _still_ use the double width type for testing purposes due to availability limitations (at least in the medium term). So that's the correct path forward no matter what. ---
**Author:** ![Sajjon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sajjon/32/12044_2.png) [@Sajjon](https://forums.swift.org/u/Sajjon)\ **Post date:** [October 5, 2023, 7:27pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/3 "2023-10-05T19:27:57Z")
Only 128 bits? Or 256 bits? Also circa 1 year since [BigInt branch in swift-numerics](https://github.com/apple/swift-numerics/commit/fd9722e60944a7152229232b318df6e17d40f1a4) had an update, any plans for thar branch to be merge to main anytime soon? ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 5, 2023, 7:31pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/4 "2023-10-05T19:31:33Z")
For the stdlib, there's a big falloff in use cases after 128b. Larger fixed-width integer types are interesting, but probably belong in a separate module or package (I'll expand on this in the alternatives considered section of the pitch for 128b integers). ---
**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 5, 2023, 7:47pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/5 "2023-10-05T19:47:43Z")
Any chance we can steal the whatever machinery C's `_BitInt` uses to get arbitrary fixed-width integer types? Obviously, this would be most useful with generic value parameters, but even a standard library only magic type would be useful for people who need bigger integers. ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 5, 2023, 7:48pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/6 "2023-10-05T19:48:51Z")
You, uh, might want to look at the codegen that `_BitInt` currently produces with most mainstream compilers before getting too enthusiastic about doing that =) ---
**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 5, 2023, 7:49pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/7 "2023-10-05T19:49:51Z")
I've only actually used it for sizes up to 128 myself, so I probably missed what it does for bigger integers. ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 5, 2023, 7:51pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/8 "2023-10-05T19:51:05Z")
I admittedly haven't looked at it for a couple months, but while add and subtract were OK, everything else was pretty dire last time I checked. ---
**Author:** ![Sajjon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sajjon/32/12044_2.png) [@Sajjon](https://forums.swift.org/u/Sajjon)\ **Post date:** [October 5, 2023, 7:55pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/9 "2023-10-05T19:55:11Z")
I’d say there is a big falloff over 256 bits, but given that most Elliptic Curve cryptography, specifically the curves secp256k1 uses by the vast majority of all cryptocurrencies and also Curve25519 also with heavy usage rely on 256 bit sizes finite fields, it would be very unfortunate to let the cutoff be 128 and not 256. ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 5, 2023, 7:56pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/10 "2023-10-05T19:56:08Z")
Crypto tends to have fairly specialized requirements on its arithmetic, however, that a general-purpose type does not satisfy. One would not implement crypto primitives using a type that doesn't explicitly guarantee certain types of side-channel resistance, at a bare minimum. You would also like to ensure that copies of sensitive data are not left sitting around on the stack or in register, which is a near-impossible guarantee to make with Swift's normal semantics. Once you leave crypto applications to specialized libraries, there are very few clients for fixed-size 256b integers. ---
**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\ **Post date:** [October 5, 2023, 8:00pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/11 "2023-10-05T20:00:31Z")
> [@scanon](#): > > You would also like to ensure that copies of sensitive data are not left sitting around on the stack or in register, which is a near-impossible guarantee to make with Swift's normal semantics. So crypto written in Swift shouldn’t use e.g. `Int`? ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 5, 2023, 8:01pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/12 "2023-10-05T20:01:24Z")
Ideally, crypto primitives should not be written in Swift (or normal C or C++ or Rust, for that matter), but this line of discussion goes off-topic pretty quickly. ---
**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\ **Post date:** [October 5, 2023, 8:03pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/13 "2023-10-05T20:03:22Z")
I don’t understand how that squares with Swift’s desire to be a general-purpose programming language. Crypto algorithms have to be written in _some_ language, and they’re currently written in C, C++, Rust, Java, C#, and many other languages. Surely we’re not saying that Swift is completely off the table for writing crypto? ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 5, 2023, 8:03pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/14 "2023-10-05T20:03:47Z")
Swift is not significantly worse than those languages. None of them are really suitable for the task at present. ---
**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\ **Post date:** [October 5, 2023, 8:04pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/15 "2023-10-05T20:04:56Z")
So then I return to my question. Given that Swift is no worse than other languages crypto algorithms are written in, should crypto algorithms written in Swift avoid types like `Int`? Edit: Steve and I were talking past each other a bit. To avoid leaving dust on the stack, control against side-chain exploits, etc., you really need to control the exact instructions in the core of your crypto algorithms, which necessitates writing them in assembly. I don’t dispute that, but you eventually have to surface it at a higher level, and I’m curious at what point it becomes “safe” to traffic in the normal datatypes. ---
**Author:** ![dmt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmt/32/30830_2.png) [@dmt](https://forums.swift.org/u/dmt)\ **Post date:** [October 5, 2023, 8:22pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/16 "2023-10-05T20:22:14Z")
One can use `Builtin.Int${N}` with `N` up to 2048 and wrap it in a struct just like stdlib does. This is `iN` type from llvm ([docs](https://llvm.org/docs/LangRef.html#integer-type)). llvm will do all the heavy lifting. Example: > **[Compiler Explorer - Swift (x86-64 swiftc nightly)](https://godbolt.org/z/4Wc1sxzba)** > > import Builtin > > struct Int2023: ExpressibleByIntegerLiteral, \_ExpressibleByBuiltinIntegerLiteral { > var \_value: Builtin.Int2023 > > init(\_value: Builtin.Int2023) { > self.\_value = \_value > } > > init(\_builtinIntegerLiteral value: Builtin.IntLiteral)... Unfortunately there're some inconvenience ahead: - Swift doesn't support compile time constants as generic parameters, so we can't generalize an implementation. - `BinaryInteger.distance(to:)` and co return `Int`, so they're problematic But still very doable. ---
**Author:** ![wadetregaskis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wadetregaskis/32/8494_2.png) [@wadetregaskis](https://forums.swift.org/u/wadetregaskis)\ **Post date:** [October 5, 2023, 9:44pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/17 "2023-10-05T21:44:03Z")
> [@scanon](#): > > To be clear: Foundation is not considering adding their own. They're recommending using the existing DoubleWidth test support from Numerics for testing purposes (at my urging). I'm aware their implementation strategy is somewhat different, but ultimately (for most purposes) the net result is the same - a 128-bit wide integer. I also don't think the fact that they're only used internally, for unit tests, negates the general problem of copy-paste reuse. > [@scanon](#): > > …Foundation and Numerics should _still_ use the double width type for testing purposes due to availability limitations (at least in the medium term). So that's the correct path forward no matter what. An important and regrettable point. Would it make sense, then, to at least put `DoubleWidth` into its own Swift package (e.g. apple/DoubleWidth) given there are at least two Apple packages that [want to] use it? That way there'll at least only be one implementation of that specific type. I realise that will then make it available to the community at large, but, so? It needs to work properly anyway - especially given it's relied on in unit tests for essential Apple libraries - so more users & more eyes on it will only help. ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 5, 2023, 10:05pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/18 "2023-10-05T22:05:21Z")
It doesn’t really rise to the level of a thing we want to put in a high-visibility package. If someone else wants to create one, the Swift license permits it and they should feel free to do so. For Numerics and Foundation, I think we’re fine with having two copies. (Foundation and Numerics both have some weird Apple-specific layering restrictions because they’re pretty low-level, which feeds my reluctance to add dependencies for either, but which other packages shouldn’t need to care about at all.) ---
**Author:** ![LiarPrincess](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/liarprincess/32/22594_2.png) [@LiarPrincess](https://forums.swift.org/u/LiarPrincess)\ **Post date:** [October 11, 2023, 1:15pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/19 "2023-10-11T13:15:57Z")
Wait a sec! Is `DoubleWidth` public? Can we use it outside of Apple? I am talking about the Swift Numerics implementation. I always thought that it is private and used only for testing, so I never filed any issues. There a few ways to crash it, but I was: “well… it is a private type used only for tests, and it works for them, so whatever”. Should I create an issue? I’m pretty busy at the moment, so this may take ~2 weeks. ---
**Author:** ![wadetregaskis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wadetregaskis/32/8494_2.png) [@wadetregaskis](https://forums.swift.org/u/wadetregaskis)\ **Post date:** [October 11, 2023, 1:20pm UTC](https://forums.swift.org/t/status-check-int128-uint128/67694/20 "2023-10-11T13:20:51Z")
> [@LiarPrincess](#): > > Wait a sec! Is `DoubleWidth` public? Can we use it outside of Apple? I am talking about the Swift Numerics implementation. It's not exported in any of Apple's packages. What @scanon was saying is that people are free to copy-paste it into a new package, or just their own app directly, and run with it from there. There are 3rd party equivalents (e.g. [Numberick](https://github.com/oscbyspro/Numberick/tree/main)). [Next page](https://forums.swift.org/t/status-check-int128-uint128/67694.md?page=2)