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.