Sarah Reichelt (Mastodon):
In Xcode 16, Apple quietly introduced the ability to format your Swift files using Swift Format. I’m a long-time user of SwiftLint, but having such a tool built into Xcode would be a great convenience, so I decided to give it a try. Here is my description of why I use such a tool, how well it works compared to the alternatives, and how I configured it for my own purposes.
[…]
The name Apple chose is logical but confusing. I had experimented with Nick Lockwood’s SwiftFormat
a few years ago, but found that I preferred SwiftLint, so I stuck with the latter. When I saw that Xcode included Swift Format, I assumed that they had acquired Nick’s formatter but it appears to be a different tool, officially called swift-format. It’s downloaded as part of the toolchain when you install Xcode 16, so no further installation is required.
[…]
After reverting to the original code again, I chose Editor -> Structure -> Format File with ‘swift-format’[…]
This fixed the indentation and the whitespace issues. Interestingly, it split the long function call and definition over multiple lines, but still with more than one argument per line.
Previously:
Mac macOS 15 Sequoia Open Source Programming Xcode
Fatbobman (Mastodon):
[prepareForDeletion is called] when the managed object is about to be deleted, typically used for cleaning up resources or manually managing relationships. Note that this method is triggered before validateForDelete. If the deletion operation fails due to validation failure, changes made in this method may be rolled back.
[…]
However, because these operations are extensions of managed object subclasses, if you don’t build subclasses or don’t operate through specific types, these methods won’t be called. For example, during batch operations, specific managed object subclasses are usually not involved, so these lifecycle methods won’t be called.
Although SwiftData’s default storage implementation is based on Core Data, it doesn’t declare managed object subclasses for each entity. Therefore, SwiftData doesn’t provide similar functionality—these notification timings are unique to Core Data.
[…]
Unlike context notifications, [Persistent History Tracking] or SwiftData History doesn’t include specific change information in the notification. Developers need to retrieve changes that occurred after a specific time from the database through code to obtain this data.
Previously:
Core Data iOS iOS 18 Mac macOS 15 Sequoia Programming SwiftData
SE-0452 (via Steve Canon):
Swift does not currently support fixed-size or fixed-capacity collections
with inline storage. (Or at least, it doesn’t do so well, not without
forming a struct with some specific number of elements and doing horrible
things with withUnsafePointer to handle indexing.) Most of the implementation
of something like a fixed-size array, or a fixed-capacity growable array with
a maximum size, or a hash table with a fixed number of buckets, is agnostic
to any specific size or capacity, so that implementation
would ideally be generic over size so that a library implementation can
be reused for any given size.
Beyond inline storage sizes, there are other use cases for carrying integers
in type information, such as to represent an operation with a particular
input or output size. Carrying this information in types can allow for APIs
with stronger static guarantees that chains of operations match in the
number of elements they consume or produce.
[…]
Generic types can now be parameterized by integer parameters, declared using
the syntax let <Name>: Int inside of the generic parameter angle brackets:
struct Vector<let count: Int, Element> {
/*implementation TBD*/
}[…]
On platforms where the vendor ships the Swift runtime with the operating system, there may be limitations on using integer generic parameters in programs that want to target earlier versions of those platforms that don’t have the necessary runtime support.
The Future directions section is interesting.
Previously:
Language Design Programming Swift Programming Language
John Gruber (Mastodon):
It also brought to mind how social media has largely kneecapped true hypertextual writing by not enabling it. You can, of course, add links to web pages in social media posts on any of the various basically-the-same-concept-as-Twitter platforms like X, Threads, Bluesky, or Mastodon, but you do so by pasting raw URLs into posts. (Instagram, by far the world’s most popular such social network, doesn’t even let you paste hyperlinked URLs into the text of posts.) The only links that work like web links, where readers can just tap them and “go there” are @username mentions. On social media you write in plain un-styled text and just paste URLs after you describe them. It’s more like texting in public than writing for the real web. A few years ago these social networks (and private messaging platforms like iMessage and WhatsApp) started turning URLs into “preview cards”, which is much nicer than looking at an ugly raw URLs. But it’s not the web. It’s not writing — or reading — with the power of hyperlinks as an information-density multiplier. If anything, turning links into preview cards significantly decreases information density. That feels like a regression, not progress.
Nick Heer:
Writing on the web is not like print, where too many citations can feel interruptive. On the web, it is just part of the visual vocabulary. It encourages a more expansive tapestry where references can be used for more than just acknowledging source material. One can also point to definitions, tangential pages, or jokes. The hyperlink is among the singularly magical elements of the web.
Previously:
Bluesky Facebook iMessage Instagram Mastodon The New York Times Twitter URL Web WhatsApp Writing
