I noticed this morning that some entrepreneurial soul did a quick rewrite of the _CShims package target in swift-foundation into Rust. I was really impressed by how this PR was handled - thanks for being kind, it reflects well on the ecosystem.
This PR got me thinking, though: is there a goal to rewrite these lower-level dependencies into Swift? It looks like it's primarily being used for UUID generation and some lower-level string comparison functions.
For anyone else interested in the context, they are referring to this PR: (Replace _CShims with RustShims #122)
I've had a naive attempt at porting the UUID shims over to Swift: Port _CShims UUID to Swift by tonyarnold · Pull Request #129 · apple/swift-foundation · GitHub
Just for reference there is a Swift based UUID implementation here: GitHub - swift-extras/swift-extras-uuid: A UUID implementation without the use of Foundation in pure Swift. that is quite performant and might be worth looking into as well
Oh, that’s much nicer than my butchered bit of learning!
Some super nice techniques in there from @fabianfett, @slashmo & @0xTim 
More importantly, UUIDv4 (which Foundation and that implementation generate) is not necessarily the best things to use in all cases.
The new UUID v6/7/8 incorporate a temporal component, which means they have greater locality and are much friendlier for databases. They also allow the use of arrays (with lookup via binary search and very easy filtering of items within a given time range) rather than dictionaries, which can be much more space efficient. Many (most?) large-scale distributed systems these days generate IDs which incorporate both temporal and spatial uniqueness (such as Firebase push IDs).
Pure-Swift implementations of UUIDv4 and v6 in my UniqueID package: GitHub - karwa/uniqueid: Random and time-ordered UUID generation in Swift
Are Apple likely to want to change the UUID version in Foundation?
I was just keen to get rid of the C shim - that seemed like a good first step to precede any future enhancements.
I think a modern UUID API would provide both, as well as more parsing and formatting options.
More broadly, the most important reason for replacing C implementations is functional - in addition to the features listed above, only a Swift implementation can allow users to provide their own RandomNumberGenerator to be used in ID generation, or allow users to parse UUIDs from generic StringProtocols (i.e. including substrings).
The current set of functionality is just far too basic and needs a comprehensive rethink.
I do agree that other versions of UUID are very important, especially for the server ecosystem. Right now the focus on swift-foundation is to implement all the APIs in Swift that are set out in the README.
Afterwards, swift-foundation does user an evolution process to pitch new APIs. Not saying that variants of UUIDs are getting accepted but personally I would love to see a pitch for them. However, we do still have a couple of important types missing and a bunch of unknowns ahead of us.
Fwiw, I settled on GitHub - yaslab/ULID.swift: Universally Unique Lexicographically Sortable Identifier (ULID) in Swift. by now.
The current set of functionality is just far too basic and needs a comprehensive rethink.
Yes, but modifying UUID in this way requires an evolution pitch. I'm only trying to reduce/remove the C shims from this project so that the implementation is all in Swift (and consistent with what is already there). This will hopefully make proposals like yours easier to implement if/when they're accepted.
If reimplementing UUID it would be great if it followed the standard of formatting in lowercase 
Foundation’s backwards-compatibility constraints are even stronger than Swift’s. Imagine someone using a UUID in a path on a case-sensitive filesystem.
That sounds like what happened when I was passing UUIDs to a C# REST API and it refused to accept them because they were in upper-case.