You have to use a nightly toolchain from swift.org, rather than one that comes with Xcode (this is mentioned in the proposal text and announcement: "this branch requires a recent nightly toolchain to build.")
You can't use tools version 6.0 with Xcode because Xcode always uses its default toolchain to evaluate Package.swift.
1 Like
Ah, thanks for the reminder; yes, you also have to build from the command-line. (Technically you can swap that out for 5.10 and build in Xcode, we don’t require anything from the tooling, but we do need Synchronization and some stdlib features that are only present in the Swift 6 nightly toolchains.)
And even if did obey your local build settings for packages, it still doesn't recognize 6 as a valid Swift version and produces an error, even when using a Swift 6 toolchain.
how feasible would it be to get that branch of swift-numerics to support Swift 5.10?
Thanks.
Ok, I've installed the latest build (5.10.0.13) that I could find. I also edited the Package file since this still isn't 6.0 and I get the following:
swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
Target: x86_64-apple-macosx14.0
mikeg@Mikes-iMac ~ % cd /Users/mikeg/Work/Tests/swift-numerics
mikeg@Mikes-iMac swift-numerics % ls
CMakeLists.txt LICENSE.txt README.md Tests
CONTRIBUTING.md Package.swift Sources cmake
mikeg@Mikes-iMac swift-numerics % swift run Int128Demo
error: no executable product named 'Int128Demo'
mikeg@Mikes-iMac swift-numerics % swift run Int128Tests
error: no executable product named 'Int128Tests'
mikeg@Mikes-iMac swift-numerics %
Am I missing something as a CL newbie?
Hi all --
After discussion with the LSG and some other folks, I've decided that it makes the most sense to add new requirements on encoders and decoders to support [U]Int128, and provide default implementations that unconditionally throw an EncodingError or DecodingError. This will allow each decoder to decide if and how they would like to support these new types without having to wrestle with compatibility with a defaulted encoding. I'll update the proposal text and implementation PR shortly.
14 Likes
It's a library rather than a binary target, so there's no executable to run. You can invoke swift test to run the tests, which is not very interesting, or swift run --repl to get a REPL where you can import the library, or include the package from another one to build code that uses it.
Hello everyone,
The author has updated the proposal to add new requirements on encoders and decoders for the 128-bit integer types (with default implementations that throw), based on the discussion in this thread. The LSG has extended the review for a few more days (until March 29th) to allow time to consider this amendment.
Thank you,
Doug Gregor
Review Manager
11 Likes
+1
Encoding of Int128 to array of smaller integers for solving current backward compatibility problems seems to be a problem itself in future. The solution of a problem become a problem on its own.
In my opinion, concerns about incompatibility are exaggerated. When a decision for usage of (U)Int128 in json is made, adopters should also:
- make other decisions about compatibility with old format (e.g. when loading old json from filesystem)
- provide support of new Type on the other side (e.g. when mobile iOS App wants to use Int128, server and Android teams should also be able to support it).
If someone e.g. begin to use Int128 and send such json to legacy server, it is expected that server will fall into error. So it as a programmer error which is caught in early development stage.
1 Like
While this statement is perfect: allowing implementations to choose their preferred behavior when they add support without worrying about compatibility with a defaulted implementation
This one is not: with default implementations that throw an EncodingError or DecodingError unconditionally
In some future other languages will also support Int128. It will be good if all integers are Encoded/Decoded in the same way by default, having an option to change / choose another coding variant.
The protocols do not and cannot do any actual serdes. That is implementation-specific, to each conforming type. e.g. how things are encoded in JSON is completely different to MessagePack.
2 Likes
This design looks good to me.
3 Likes
Will these types be supported by JSON and PropertyList coders as well at release? It's a bit odd that it would be released with Codable conformance, while simultaneously not being supported by the coders that most folks would reach for, especially if they are just using those coders for things like local persistence.
What about the idea of adding a warning so that creators of custom Encoders and Decoders have some notice about these new customisation points?
1 Like
That's a Foundation question, outside the scope of a standard library proposal. However, we would treat adding support for these in Foundation a bugfix.
As a more general principle, for any Foundation API that supports all standard library types conforming to protocol P, if the standard library adds a new type conforming to P, Foundation considers adding support to be a bugfix that doesn't need proposal or discussion, unless there are specific implementation difficulties that would make adding support problematic.
6 Likes
2 Likes