This announcement comes with some answers to “what should be in the Swift standard library?”
Almost all library features can be composed from existing features with enough effort. To be considered for addition to the library, a proposed feature must satisfy two conditions: it must provide functionality that is useful to a substantial population of Swift programmers, and it must provide substantial advantages over the alternative ways of accomplishing that functionality. Potential advantages include:
It may be complex, challenging, or error-prone for users to implement themselves. It may have substantial performance advantages over a user implementation, either because it has access to library internals or just because the library implementation will likely be more carefully tuned. It may be substantially easier to work with because it composes better with other language or library features. It may be substantially more “fluent”: that is, more natural to discover, use, and read in code. The implementation may involve composing primitives in a subtle or tricky way, or the primitives may be unfamiliar to many programmers. This is a more subjective criterion than the others, and people may reasonably differ about how to apply it. For example, consider adding an method to rotate the elements of an array. This operation can be performed using a relatively simple composition of slicing and concatenation:
array = array[amount...] + array[..<amount]
However, a method to rotate an array in-place would still be welcome: it would have substantial performance advantages, it would avoid several potential off-by-one errors, and it would be significantly easier for a reader to recognize as a rotation.
In contrast, a property like
isNotEmptyoffers no substantial advantages over
!isEmpty, and adding it would open the door to adding trivial negations of essentially every predicate.
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!