This is a superthread where I will link to threads for my open source libraries.
I have two goals in sharing libraries with the community:
- Share the wheels I keep reinventing on engagements
- R&D on advanced Swift design
The first goal is for me to contribute the work I have done on past projects that is useful to Swift development in general to the community so the full benefits of those tools can be realized. For the past 5 or so years I have repeatedly built up a similar set of utilities or abstractions I find useful for building Swift apps. Not only do I want to reuse that work on my own future engagements in a formalized way, I want to share the benefits I get from having those tools with the Swift community.
The second goal is to showcase my exploration of the design space allowed by Swift’s now very advanced and powerful expressivity. For my own curiosity and to improve my Swift skills I have been exploring how to implement various functionality in Swift in a way I describe as absurdly type safe, where the goal is to enforce as much business logic at design time (what we usually call “compile time”) as possible… to a much further degree than developers, me included, typically try to achieve. Since these are just personal “side projects” that aren’t necessarily tied to professional engagements, I have the freedom to experiment with approaches I’m less sure of, or that would cause too much grief for other team members who aren’t familiar with (or actively dislike) this style of programming (and I can’t evangelize it too hard if I’m not sure of it yet either). I can explore techniques to achieve what may seem like an excessive level of design time enforcement that requires more upfront work and is harder to use at first, but that “hardness” is actually the compiler debugging your code as you write it. What this mostly looks like in Swift is heavy use of protocols and generics (compared to the typical style I see from other Swift devs, much less reliance on enums and closures/blocks), to the point that nearly all the code is generic with several type parameters and protocols all have several associated types, and what most devs would normally represent as values (instances of a type) are represented as types (lifting the data into the static type system). I also expect that macros will play an increasingly large part of this moving forward.
I should also point out that my libraries currently focus only on Apple platforms, but I may start trying to bring in other platforms eventually.
Even though these libraries (in the second category) are driven forward by design research, they do almost always emerge from real problems I have encountered, should have real world value, and are available for use in projects. My requirements for a library being presentable do not include documentation, but do include 100% test coverage. The main value in my view is for developers to inspect the source code to stimulate thinking about Swift design, and then decide to add one as a dependency if they find it useful. So documentation is nice to have but not essential, but correctness is essential, hence the test coverage requirement. I generally don’t like projects having lots of third party dependencies, especially of smaller libraries, and lean toward recommending that teams copy in the code they want to use into their own codebases. But I am crafting these libraries as SPM consumables for anyone who wants to use them that way.
I will shortly follow up with the first set of libraries that are now ready and link to a thread for them from here.