Swift Package Indexing

In our previous episode, we had the cutting title,

"Now I'm Worried If Our Metrics Are Correct."

Yes, we did. That was when we were talking to Holly, right?

Yeah. Narrator, they weren't.

They weren't as bad as we feared, though.

So we did indeed have a misconfiguration, but the effect wasn't catastrophic.

And we should say, in our defense, we did test this with a few packages before

making these runs, obviously. But you inevitably miss edge cases when you go from,

you know, like a handful of packages to 7k packages.

But I found it really interesting how that was triggered by our conversation with Holly

when I did a little quiz, right? And Holly went really low in how many packages she thought might

have zero reporting, zero errors. And I think you were pretty close.

Yeah, I think I was within a thousand or something like that.

Yeah. So the percentage I quoted was 53.2% of packages reporting zero errors. After our last

run, it's lower. It's 40.8 packages. So it is a large correction, but it's also not like,

you know, like 10% only. You know, it's like a significant drop, but it is within the ballpark.

There's still issues that we see, right? The latest one had packages that are known to be

Swift 5 compatible, well-known packages that don't build in the Swift toolchain. So they aren't

reporting zero errors because the build fails. So this number is also, there's never going to

be a correct number. We're just going to try and do our best to approach a number that

has a good reflection of what the ecosystem looks like. And that's a matter of both the toolchains

improving over time, because we have to bear in mind, these are preview toolchains.

So they will have issues of their own. And we've actually seen some of them pre-runs in our testing.

And we found some workarounds for those. And there's also, you know, the aspect of packages

working on fixes and having just things that break because of the nature of Swift 6 being

in preview right now. So yeah, that was a little follow up on the episode title.

Well, the most important part is that it didn't change the outcome of the quiz,

and I retain my quiz champion title.

Oh, there we go. Points awarded.

We should actually talk about two other data points on that chart that we're going to,

if you've been following along through pull requests, because it's not live on the site

yet, you may have noticed that there are two data points at the beginning of the current chart,

which are very out of sync with the rest of the data points that we have there.

And we're going to remove those two data points because

there's always a question when you put a chart like this, is it going to mislead people? And

that's what we do not want to mislead people. That's not our intention.

The first two runs of the compatibility testing that we did, we were only able to get working

Swift build commands rather than Xcode build commands. So that took us down from our current

list of platforms, including iOS and watchOS and tvOS and iOS and MacOS using Xcode.

And it took us down to Linux and MacOS using Swift build. And that was interesting data to

have at the time because it gave us, well, it gave us a sense of some numbers, but also it

lets us test this process of running all of the builds past the Swift 6 tool chain. So it was

important that we did those, but actually it's those two data points that are misleading. And so

we're going to knock them off the beginning of the chart so that the chart doesn't mislead.

It looks like everything got a lot worse on the third one, but actually in reality,

we just didn't test all the platforms until the third one.

Yeah, exactly. We had like a snapshot slice of the full picture really only in the first two runs.

And as you say, it was really useful to get us set up and running. I think it's always great to

just get the process going right in that case, especially because it's quite involved. Just the

fact of the act of running it was really helpful, but the data isn't. I mean, the option obviously

would be to just keep doing that only, right? Then it would be comparable, but that's also not

a good result, right? To only look at Swift PM builds across those two platforms. So since we

can't go back and run Xcode builds for the old ones, that's really the only option is to just

discard those and just start from what we've got.

I mean, we kind of could because we could install the old. Oh no, we can't because those old,

it was, yeah, we couldn't. Yeah, there was a couple of changes with those tool changes. Yeah,

yeah. It's just not possible to do it yet. So, and I think that page is going to go live

fairly shortly. I think maybe this week even we might put that page live to start publicly

tracking the Swift 6 status of all our packages.

Yeah, that's great. And we'll probably have another data point in two weeks. So I looked

a bit at the calendar to plan these a bit. And I think every two week cadence is realistic and

doable and interesting as well to space out the points a bit and give us a view of trends and

stuff.

And part of what is making that two weeks cadence feasible is some other news that we're not going

to talk about in depth today because we will talk about it in depth on a future episode. But I think

it's worth a little tease now. We have a new macOS build environment for all of our compatibility

builds. So one of the ironies of our build system is that the Linux builds were more isolated and

more independent of their environment than our macOS builds because our Linux builds use Docker.

And so every time we do a Linux build, it spins up a new Docker container and does the build and

then drops the container and everything's back to as it was before. But with our macOS build

system, we were running bare metal Macs. And of course, we then run lots of builds past the same

versions of Xcode on the same machines, but they don't have isolation. They don't have

the kind of the... Well, it is isolation. That's what they don't have. They don't have isolation.

And we've been working with Mac Stadium for the last couple of months to fix that problem,

basically. So we're moving to an Orca-based build system, which is their Kubernetes

orchestration system over, but for macOS host machines. And so we will talk about this more

and the whole setup because it's actually quite a fascinating process. And we've ended up with this

quite robust build system out of it. But one thing that is... These Swift 6 builds that we've

been doing have been an amazing test of that system because the last two runs of the Swift 6

compatibility builds have all been through our Orca cluster now. And it does give us complete

isolation. So for every single Swift build or Xcode build that we do, we spin up a new virtual

machine, a full VM, not a Docker container because we need the full VMs. And we do the build, and

then the VM gets destroyed and goes back to the base image. And then the next build starts and

starts a whole new VM. And we can have VMs configured for different operating systems like

Xcode 14s need Sonoma... No, I'm getting that wrong. Some operating systems need some

specific versions of Xcode. And we can have that. So we can have like a Swift 5.9 image that has

the right operating system and the right version of Xcode. What's even more funny about what I

just said is that I was the one set those up. So there's no excuse for me not to know the pairings,

but they're hard to remember. So yeah, we've been running this as a kind of test

for the last couple of runs. Our current production builds are still on our existing

system. But I think we're at the point where we could switch over to that new system

eminently. Yeah, absolutely. Because we are effectively we ran from the same

queue, we triggered builds on both systems in parallel. So all we did in our preview runs is

that Swift 6 builds we sent to Orca, while all the other builds went to the old build system.

And changing the targeting is just a matter of changing some labels in the

runner setup to send the other builds to Orca as well, or just through them wherever.

Again, we shouldn't talk too much about this, but this enables us not only to get more

reproducible results and more stable results because of the isolation and the security,

it means that those builds can't do anything to our systems, which would have theoretically been

possible in our current system. We were lucky never to have that problem, but we were a little

open to it, even though they ran on non-privileged accounts and all, there was other things like

that that we'd done to lessen the impact of that. But it also allows us to plan more features for

the future. Like for example, we could potentially include more dependency setup inside the virtual

machines because it wouldn't be necessary for every build to run in that environment. So we're

not announcing anything there yet, we're not even committing to that feature, but it does enable

interesting future directions. Yeah, and that's actually another point where Linux is in the

advantage currently, because that's what we actually support there. We have a couple of

repositories that need specific Linux packages to be system OS level packages to be installed in

order for them to build successfully. And the way we allow that is we allow them to specify

pre-built underlying images that are used instead of this Swift 6 image to run the builds,

so that they have their environment set up as they expect. And these are just used for those

packages, so they don't influence other packages. And that's a great feature and great flexibility

that we might potentially gain on the macOS side as well. I think one of the problems that's always

going to plague the macOS side a bit is that these images are just huge versus, I mean, the Linux

ones aren't tiny either, but Mac takes that to a whole new level in sheer image size.

I believe the images are currently 90 gigabytes.

Yeah, that's almost two orders of magnitude more than, well, it might even be more than two orders

of magnitude than the Linux images. So that's significant.

Which makes it even more remarkable that these VMs spin up in about three seconds.

Yeah, or even the cold start, you know, when the image needs to be fetched isn't that terrible

either.

Yeah, cold start is about three minutes, isn't it? Yeah. Anyway, we'll spoil talking about this

on a full episode if we talk more about it. So let's move on.

Let's do it. There's another bit of news that is sort of related to our last episode,

and that's an accepted proposal, SE0435, which allows setting Swift language version per target.

Now, if you recall, we talked about this in our episode with Holly.

We mentioned there that you need to opt into Swift 6 language mode in order to fully adopt

concurrency checking or set the flags, but opting into the language mode is the easiest way to do

that. Now, previously, this was only possible on the full package level. So you could, this

was an option in the package manifest. You could set the language version, but it would apply to

all the targets in your package. And with this proposal, you can actually do this on a target

by target basis, which is great if you want to transition slowly. You know, you might have lots

of targets, some of which are harder to transition over, and then you can just pick your battles,

switch the ones that you can, you know, want to start with early and then leave out the ones that

might be more complicated to do. So that's a great thing to see in place. So that's accepted.

And I think that automatically comes with a implementation and should be in tool chains soon.

- Fantastic.

- Right. In other news, do you know what a flipper zero is?

- It's what a dolphin does when it wants to get your attention.

- Right. I'm not sure how that relates to Swift, but this flipper zero I'm talking about is a

portable multi-tool for pen testers and geeks in a toy-like body.

- Oh, that kind of flipper zero. Of course I knew what that one was.

- Yeah, there you go.

- I thought that one was too obvious. Yeah.

- Right. So it's a little microcontroller device with a screen and a D-pad, and it has a C API,

and they can probably see where this is going. This is another one for the section,

Swift in unusual places. Samar Sunkaria posted on the Swift forums about this, a proof of concept

to target this device and, you know, add a Swift API layer on top of that C API to be able to build

apps for this, or, you know, ship binaries to this microcontroller thing. It has a display

and a D-pad, so I'm not sure actually what you could, you could probably ship Doom on it,

but this might be interesting in terms of getting more stuff on it to do, you know,

what this is actually intended for, like pen testing and that sort of thing. I found that

interesting. I found it especially interesting that this, we've seen this embedded Swift popped

up, was it like three, four months ago? And since then, there've been like three, at least three

proposals or implementations I can think of where people added APIs using Swift over C APIs and

shipping this to these microcontrollers. So that's really interesting. And I hope that trend continues

and becomes more mainstream. I found that really nice to see that this is really being picked up.

- It's always nice to see it arrive on a new platform. Yeah.

- Yeah. And I think it goes to show that this is really powerful to be able to

sort of insulate people from the C API. I mean, I get why these ship with C APIs, because that's

the most platform agnostic thing to do, right? Or I guess one of the most platform agnostic things

to do as a vendor for this thing, but then the ease with which apparently, you know,

people can layer on top richer, you know, or different language adaptations that make it

easier to work with. I think that's a superpower. And I hope that gets used a lot and becomes more

popular. - And you mentioned running Doom on it.

That reminded me of a story I saw recently that somebody got Doom running on gut bacteria.

- On what? - Which was a story, gut bacteria.

- Like in a simulation or actual? - No, in actual gut bacteria

at a resolution of 32 by 48 pixels. Unfortunately, the cells take 70 minutes to illuminate and

8 hours and 20 minutes to return to dark. But through manipulation of gut bacteria,

you could, they did get Doom running on the gut bacteria.

- So in terms of frame rate, that's not gonna be great, is it?

- It does say here, it says, given that the original game runs at 35 frames per second,

the cell display would take 599 years to play Doom from start to finish.

- Oh God, that still sounds quicker than I would have thought.

- We'll include, as a completely relevant link, we'll include a link to that in the show notes.

- Fantastic. - But you really can play Doom on anything, yeah.

- That's amazing. You've probably seen the one where they ran, I think it's Doom,

where they run it on the CPU load widget on a supercomputer.

- Right, yes. - So someone has a panel up with however

many CPUs that thing has, arrange them in a grid, and then just by creation of load on the system,

they light up the pixels. It's kind of nuts. - Yeah, I love that it has become a thing.

- Yeah, great. We got another one for our different segment, which is Swift on non-Apple platforms.

And this is a post by Jeremy Dave from the Browser Company about Swift tooling on Windows.

You may have seen this one, Dave. - This was a few weeks back, right?

- I've seen this last week. This might be a different post than you're thinking.

- Yeah. - So this is specifically about Swift tooling.

It's not about how they implemented Arc, which is their browser and the Browser's Company

main product, which is known for. It's implemented in Swift on Windows. So they ship this whole

thing. This is about the state of tooling on Windows. And it sounds like things are going

really well over there. And I've been actually using Arc on Windows for a bit recently,

and it's really a great app. It works great. And I'm no expert on what makes Windows app feel

truly native, but it certainly looks absolutely fine to me. I wouldn't be able to tell the

difference. - Well, they are using the native APIs.

They're using Swift bindings into WinRT, which is the native Windows API.

- Yeah, exactly. - So it should feel native.

- Yeah, it should. Absolutely. I just wonder, sometimes it might not cover everything. So

you might see some oddities because certain OS level things that are typical aren't available,

and there might be workarounds. That's the sort of thing I was thinking about.

- Yes. - But there's none of that. But then again,

I probably wouldn't be a good judge of it anyway. But the post isn't really about Arc.

I don't think it even mentions Arc. It talks about what tools they use to develop Arc,

which is obviously VS Code as the editor, as the IDE. They go on to talk about the debugging,

what they use, LLDB, but also that you can use Windows native debugging tools that aren't

specific to Swift, and they can be made to work with this. And they also go a bit into

how you can use obviously Swift PM, and that's what they use mainly to build the binaries. But

you can also use CMake if you have special requirements that aren't covered by Swift PM,

that sort of thing. And that might be related to Windows APIs that you need to integrate with,

or Windows libraries you need to integrate with, or issues that might need to work around,

because on Windows there's a 64K limit in terms of, I think, how many symbols you can export in a

DLL. And for that reason, you might... I think that's the reason why you need CMake to build,

and to strip out stuff that you don't need to actually ship in a DLL. It's an interesting post,

even if you're not developing in Windows, just to see how stuff works over there. And yeah,

I found it a nice description of how that goes. And I'm actually particularly interested,

because I'll start poking at this a bit with Swift on Windows in the near future.

One interesting other thing I saw mentioned is they talk about tools, Swift tools, that are

shipped with a compiler. And one thing in particular is Swift Inspect, which I don't think I'd heard

about before. And there's a subdirectory inside the Swift compiler with tools, and that's where

this lives. It's not a separate package. It is a package, but it's embedded in the Swift repository.

And it's a tool that allows you to inspect a live running Swift process and dump some info. It's not

like... The info is very specific. It's quite niche. So you can, you know, like array information and

cache information, that sort of thing. But I found it interesting that there's stuff in the compiler

that's shipped as Swift packages. And it might also be interesting for people who are poking

around and might want to see how that sort of stuff is implemented. That's why I wanted to

give a shout out to that particular tool. So interesting stuff there coming out on non-Apple

platforms. Yeah, it is.

Yeah, finally, a bit of news that is about performance benchmarking. So it was a long

Swift forum thread about performance benchmarking. And I did all this one. Yeah,

you saw that one. Yeah, I think it was hard to miss. I found it really interesting for a number

of reasons. And they're probably not all obvious. It all started when Axel Rost posted a benchmark

result and asked for help on the Swift forums. And it's about understanding the results that

he saw, which were weird. So he used Vapor, a Swift server framework to run the performance.

I should say what the performance benchmark is about. This is about running a web server,

web framework, and to test its requests throughput. You know, how many requests can it handle per

second and compare different languages and frameworks like Node, PHP, I think, and Python

are the three other language framework combinations he looked at. And he saw interesting results in

general, but in particular, he saw that Vapor Swift was dropping 1.5% of all requests, which

is odd and off the start without any load. And that's the question he asked on the Swift forums.

And if you've ever seen a nerd sniping of epiphyte portions, that was one. Because everyone sort of

dropping across. Yeah, this was. Yeah. And then people obviously also looked at the performance,

the benchmark itself, because that was also quite low. Swift wasn't doing great in terms of

request throughput, which seemed odd, because there was nothing really that should make it,

you know, it should have done better, I think. And it did in the end.

But it was really interesting to see how there was not one single thing that was wrong,

and obviously wrong. And it took a lot of really skilled people to poke at it to find out what was

going on. And I think it's really hard to summarize the results here, because there were so,

so many interesting outcomes and questions being asked and investigated and

sort of assumptions being tested and revised. It was an interesting thread.

I think one of the things that came out of it was your benchmark methodology is really important

and was somewhat problematic here, because he was creating load as a benchmark and then

testing something slightly different when he's what he thought he was testing.

And that was partly a problem was on Swift that in order to create the load, he used a third party

dependency in order to compute the thing that he, he will use the Fibonacci sequence to create the

load. But the package used to do that on Swift wasn't actually well maintained. It was quite a

lot slower than the other implementations, which use native highly optimized

implementations of big int to do that thing. So that was sort of a not a like for like comparison.

Then Vapor had a default config, which wasn't ideal for this sort of test scenario. And perhaps

even in general, there were some system limits on the OS's that he tested that were too tight,

like maximum file descriptors and maximum outstanding socket connections being allowed.

So that was interesting. And that wasn't just Mac OS, also Linux, these were,

these should have been tweaked in order to make this a decent, normal test, you know,

like you would normally test this because you don't want to test the system limits, right?

You want to test the framework limits. So that was just, I think I listed five there,

there might have been more, but it's just a really interesting thread about performance

benchmarking and like how predictably it'll attract lots of, lots of interesting discussion.

And it was, I think it is notable that this was a good discussion. It was a really interesting

discussion. Well, that's what I was going to say. Yeah. I thought it was really one thing that was

really struck me in reading. I didn't read the nitty gritty of every post on it because it was

an extremely long thread in the end. But what I thought was really nice was how not only the

people from the Swift side, but the benchmark, the person who was running the benchmarks

was willing to accept that neither side was perfect in their initial kind of testing.

Where sometimes, and I'm not accusing this of anyone in specific here, but sometimes

people produce a benchmark to prove their point. And once their point is proven, it's hard to,

it's hard to move them away from that original kind of benchmark. But I thought this was a

really great example of collaboration between people. Yeah. Yeah. And it's also, I think it's

also the proposition of the benchmark is really important because there's different ways of going

at it. You can test default config and make your argument. Well, that's what people are going to

use. Right? I mean, lots of people, obviously Google, Apple, aren't going to use it like that

because they know how to test the best possible case. So you think you always need to have almost

like two benchmarks. One is the default, which people will use and which will be seen in production

because that's what people start off with. And then perhaps at the other end of the spectrum,

the one that's tuned to the guilds and everything is taken care of. And, you know, every,

every little bit is tweaked and that's what you look at as well. But I think neither is perfect

in assessing what will be the result for you to choose a framework because, I mean, we run a web

service and we use vapor quite a bit and we sort of look at stuff, but we are using the defaults.

I don't think there's a lot that we've tweaked. So if there's anything that would, you know,

we would benefit of the defaults changing as a result of this. And I think that's why these

default testing benchmarks are also really important because you have a huge impact if

you make improvements there, because all the people using the defaults will see that that

benefit trickle down. But I think the real summary should probably be only trust the benchmark where

your favorite language framework comes out on top, isn't it? Well, that was kind of my point. Yeah.

Once you've proven, once you've proven what you thought you were going to prove, why,

why do anything else? Right. Stop right there. Exactly. Yeah. Yeah.

Should we do some package recommendations? Yeah, let's do it. Do you want to kick us off?

Because I really have only two this week. That's okay. We can do two each. I can kick us off with

a package called Swift Chess Neo by Navan Chauhan, which is a cross-platform Swift chess library.

Now, I'm not a big chess player. I can just about struggle through a game, but

don't talk to me about tactics. And this is a work in progress library, which is actually

a fork of a package called Sage by, I should have had this information ready, by Nikolai Vazquez,

which is a no longer maintained Swift package for a cross-platform chess. And this Swift Chess Neo

is a fork of that along with some patches from someone. And it also adds Swift UI views.

But what does this package do? It does much more than just visualize chess, which is the Swift UI

bit of it. It does game management. It does move execution. It has all the rules encoded, of course.

It has move generation. So it would be possible to build from this package into a chess game. And in

fact, the person does say, Navan does say, I'm actively developing Swift Chess Neo while writing

iWatchChess for iOS and macOS. So this is the core logic for an app which is being produced at

the moment. And it can also do visualizations in ASCII. So you can look at the board while you're

debugging and it will print out an ASCII representation of the chess board. And it

understands all of the chess notations so that you can input your chess moves in with a notation

rather than having to deal with an API, which would not be as efficient to kind of code against.

And I thought this was just a really nice example of a little package that most people won't see.

And yeah, if you have any interest in chess whatsoever, I think you'd find something

interesting here. So the package is called Swift Chess Neo. And Neo is...

N-E-O, yeah.

N-E-O, yes. Because until the world halfway through of your description, I was sitting

here thinking, what on earth does chess have to do with Neo?

How is the network going to get involved?

Yes. Until you said Swift UI, then that's when it sort of started clicking. And I thought,

oh, right, the other Neo. That's really interesting.

In Swift 7, all network requests will have to go through a chess board representation before being

executed.

I'm really curious what the transcription is going to make up this segment.

Yes. Yes, that will be a good test of Whisper's AI. But yeah, it looks great. And it's not N-I-O,

it's Neo, N-E-O.

Excellent. That's interesting.

Like the man from the Matrix.

Nice. Right. My first pick is called Swift Security by Dmitry Zarov. And it's a Swift API

layer for Apple Security Framework. So that's keychain API, shared web credentials, API, etc.

And so I've been using a sort of a keychain wrapper in some of my command line tools. And

that's sort of like a wrapper. It's just a single file that abstracts over the keychain APIs,

which are a bit awkward. They're very C-like. I'm not even sure if there's any glue in between,

or if you're really just calling into the C directly. But you know the ones I'm talking

about, right? The sec item stuff where it's like a really non-Swifty API. So I had this file. It's

been a while since I wrote this. And I would probably switch to this instead, which has a

really nice Swift API, not just for the keychain parts of it, but also all these other parts of

security framework. So it looks like a really complete wrapper around this. And yeah, a nice

package for this. And I know there's others. The package index might be a nice place to look

around if you have needs for that. You might not need the full security framework, maybe just the

keychain API. But this is one that does all of it and might be worth checking out. So that's Swift

security by Dimitri Zarov. It's interesting that the API is where, you know, Apple could have made

a new keychain and security API that fitted in slightly better with Swift. And in those areas

where that hasn't yet been done, or it's maybe not been done to the community's satisfaction,

you'll see a collection of packages. And there are so many, there are so many keychain packages.

Actually, I wonder if Apple could use that as an indication of where they need to focus attention.

- Absolutely. It's a blossoming of packages on the fertile ground of, obviously, APIs, isn't it?

- Exactly. Yeah. But yes, there are lots of them, but this one sounds like a good one.

- Yeah.

- My next package is by David Beck and it's called Swift Glob. And it's a native implementation

of Glob pattern matching. So the Glob pattern matching that you can do in a file system,

where you can do like star, star, star, star, dot, Swift or whatever. It brings that into

a Swift UI, not your search UI, but a Swift user interface, an API user interface,

where you can very quickly include and exclude Globs from a search in a directory. So you pass

it a directory, you pass it in a set of patterns to include and a set of patterns to exclude,

and you would get back a list of files that match the combined set of everything that you've passed

to it. And I think there's obviously lots of ways to filter the files you get back from the

file system, but Globs are something that have been around for a long time and they're a really

efficient way to represent file system searches that I don't think anything else has come close to.

So it's nice to be able to use that inside a Swift application.

- Yeah, it's nice, right? Because it's just familiar, right? You know immediately how to

use that, but without understanding, you know, the regex syntax and that sort of stuff. I mean,

probably if you have very specific needs in filtering, you might need more, but it's just

such a well understood concept that it's nice to see that being available. Nice.

- And so it's a fairly new package and it only has nine stars. So if you are interested in Globs,

go and give it a star on GitHub. Because it's the kind of thing that this is a perfect use for

a package. This is something that's not going to, you're not going to build your whole application

on this dependency. So it's easy to replace if it turns out not to do what you want it to do,

but it just, it's going to save you time if you're doing lots of file system querying.

- Yeah, yeah, absolutely.

Right. My second pick comes in the shape of a blog post, actually. So I'm sneaking a lot of

sort of a blog post into the package pick section.

- This is one of my famous non-pick picks.

- Well, it is a pick, so you can use it as a dependency. It's just not,

it hasn't been packaged up yet. Maybe this is an encouragement, although I think the author

is quite busy. The author is Rob Nepeer and his blog post is about any coding key. That's what he

calls the thing, the type that he implemented. It's a really interesting blog post. He looks at

explores the coding key protocol and what it means to conform to it.

And especially if you want to conform to it yourself, you know, other than like you normally

would with a string backed enum, right? We all know this. If we have, for instance, a thing that

we want to decode and the property name, we want to have a property name on the Swift side that's

different from the property name in the JSON, for instance. Right. What we do is we have an enum

that conforms to coding key. Then we spell out the cases, also the ones that we don't want to change.

And for the ones that we do want to change, we give the case name. We assign a Swift case name

and assign it a stringified, the string of the JSON attribute name that we want to map to it.

So that's what you normally do. There's a bit of repetition going on there because you need to

spell out all the other cases that you don't want to change, but that's just the way it is.

And Rob explores what it means to implement this any coding key thing that allows you to do that

a little bit more elegantly, more concisely. And it's a really nice thing. It's a tiny type. It

really like my packet recommendation is effectively a code block in a blog post. So you can copy that

out. And there's a second code block that makes it even nicer with an overload or an extension on

JSON decoder to make that nicer. And it all lives in a repository, but the repository isn't

the package. It's a collection of, I think there's playgrounds in it and just code snippets

that explore more around codable. That's definitely also a thing worth looking at.

So the whole thing is a blog post and also a protocol, not a protocol, a repository that

Rob has prepared with lots of examples and stuff. So take a look at any coding key by Rob Napier.

All it needs is a package.swift.

Yeah. Get working on that, Rob.

Or somebody else. It doesn't have to be Rob.

Exactly. With attribution, of course.

Although it's always interesting because if you publish code on a blog,

what license is that code being published under? I mean, it's technically not an open source

license unless explicitly stated. So just be careful. Be careful taking code off people's

webpages. I'm sure this is provided in that spirit.

You're listening to OpenAI.

And with that, I think we'll wrap it up there. So we will be back in a few weeks with

another episode. And maybe by that time, we will have the, in fact, I'm pretty sure by that time,

we will have the new build system in production. So maybe we'll talk more about it then.

And we should have the Swift 6 preview live by then as well, shouldn't we?

We'll definitely have the Swift 6 preview live by then. Yes.

Yeah. Well, we got ourselves two deadlines then.

Two deadlines. Yeah. Before the next episode. But we haven't said when the next episode will be.

Well, there we go. That's our escape hatch.

All right. I'll speak to you in a few weeks.

All right. See you then. Bye-bye.

Bye-bye.