1

When working on a Decimal128 implementation (as an example), it would be great to be able to use the new StaticBigInt but this doesn't seem to be easy to do in a Swift Package with backward compatibility.

Here's what seems to work:

  @inlinable public static var pi: Self {
    let p: ID.Mantissa
    if #available(macOS 13.3, iOS 16.4, macCatalyst 16.4, tvOS 16.4,
                  watchOS 9.4, *) {
      p = ID.Mantissa(bigInt: 3_141_592_653_589_793_238_462_643_383_279_503)
    } else {
      // Fallback on earlier versions - same number in hexadecimal
      p = ID.Mantissa(high: 0x9AE4_7957_96A7, low: 0xBABE_5564_E6F3_9F8F)
    }
    return Self(bid: ID(exponent: -ID.numberOfDigits+1, mantissa: p))
  }

Is this the best way to use StaticBigInts in a Swift package? Or is there a better way?

Because it's awkward to define the StaticBigInt as a backward-compatible integer literal, two distinct initializers were required Mantissa(bigInt:) and Mantissa(high:low:).

2 Likes
2

You can express a higher minimum deployment target in your Package.swift. That will require that you only run on platforms that have a new enough Swift runtime to support StaticBigInt.

3

Yes, that would be possible, but, to maintain backward compatibility, older OS users would be required to use an older package. Essentially, to support both sets of users, it would become necessary to maintain two separate sets of source code. This would be inconvenient but not impossible.

1 Like
4

is there a specific reason why you are interested in maintaining compatibility with older macOS versions?

i ask because i too once cared a lot about back compatibility with older macOS and older toolchains - mainly for philosophical reasons, and i used to spend a lot of effort maintaining that compatibility. but time and rising interest rates have convinced me it's not worth the effort.

5

???

6

getting off topic but:

this is kind of anecdotal (though ive always assumed it was well known) that as recently as 2 years ago people were extraordinarily patient and if you wanted to say, delay a launch by a month or two to give back to the community, you had the latitude as a founder/developer to do that. because where the hell else would they put their money?

nowadays when your potential backers can earn 6% risk free, there are very few people who are willing to wait around while you implement things that are not laser focused on the core business. for me personally, that meant prioritizing deploying on linux over macOS, which has little relevance on the server.

3 Likes
7

Ok, no backwards compatibility. Thanks for the anecdote and advice.

8

Ok tried limiting the OS version in the package but still get the same compiler messages that essentially force the version check in code. BTW, you can't currently do a 13_3 OS check in the package. Just macOS 13 is supported.

1 Like
9

You can use version strings in the package manifest:

let package = Package(
  name: "…",
  platforms: [.macOS("13.3"), .iOS("16.4"), .tvOS("16.4"), .watchOS("9.4")],
3 Likes
10

Thanks, that seems to work within the package.
I didn't realize that syntax was allowed.