In this awesome post, Xiaodi summarizes the design space for string literals with a focus on raw strings and custom dilimiters. Then he proceed to some conclusions in Swift’s potential design for raw string literals.
I had the feeling that this is one of those things I’d benefit from re-reading over and over in the future.
Shannon has praised Kite at work a bunch of times and we finally got a version of these praises in words! Having read this post, Kite remindes me of Flash (the program), which I spent countless hours playing with and learning about animation for the first time. Good memories.
In my very limited reading-only experience about Lenses, this is the first article that acknoledges Swift’s value type and the fact that it makes getter/setter aspect of lenses kind of pointless. But it moves on to explain why lenses/prisms still can be useful in a concrete and approachable way.
I really enjoyed the bonus discussion about duality at the end, too!
This is an article I wish I had writen. It has everything about Swift and C, as stated in the title. It’s going to be a useful reference to me. I also wish I’d discovered it earlier.
Follow the author Umberto Raimondi on Twitter!
An oldie but goodie from Swift Evelution. Slava’s answer:
“when we talk about the ABI, we’re really talking about three orthogonal “axes” along which we would like to “move” without breaking compatibility with existing binaries:”
The first axis is the machine-level calling conventions and memory layout. For example, what registers to pass function arguments and returns in, the rules for alignment and padding of fields in an aggregate type, which entry points the Swift runtime exports and what their behavior should be. Once we commit to a stable ABI along this axis, you will get interoperability between compiler versions – the same exact library built with one version of the compiler will remain compatible with clients after being recompiled with another version, because their conventions will match up. Note that this does not help you if the library itself changes in any way.
The second axis is the resilience work I called out in my previous e-mail. Here, we’re trying to define language features and implementation techniques that allow a library to evolve in a forward-compatible manner, as long as the developer follows certain guidelines. Here, the goal is if you should be able to compile your library, make some changes to add new APIs, and recompile it with the same compiler, without breaking downstream clients, as long as you follow the library evolution guidelines (Also, you can imagine one day having an ‘ABI diff’ tool to automate this). >
The third axis is the standard library itself. Stability of runtime interfaces and the extra indirection to enable resilience is all great, but it won’t help you as long as the standard library API is evolving in a non-backwards compatible manner – for example, if we remove a method on String. So once the other two areas have been addressed, the last thing to lock down is the standard library interface itself.
The rest of the thread is worth reading too. John McCall gave an high level description.
The definitive source for Slava’s third axes is the Library Evolution doc from the Swift repository.