{"id":12821,"date":"2026-09-30T14:20:00","date_gmt":"2026-09-30T11:20:00","guid":{"rendered":"https:\/\/handoli.com\/index.php\/2026\/09\/30\/using-swifts-some-keyword-beyond-swiftui\/"},"modified":"2026-09-30T14:20:00","modified_gmt":"2026-09-30T11:20:00","slug":"using-swifts-some-keyword-beyond-swiftui","status":"publish","type":"post","link":"https:\/\/handoli.com\/index.php\/2026\/09\/30\/using-swifts-some-keyword-beyond-swiftui\/","title":{"rendered":"Using Swift\u2019s \u2018some\u2019 keyword beyond SwiftUI"},"content":{"rendered":"

Developers who have worked with Apple\u2019s SwiftUI framework have likely encountered the some<\/code> keyword in the context of defining custom views, where it\u2019s typically used to enable the generic View<\/code> protocol to be referenced as a type when declaring a view\u2019s body<\/code>:<\/p>\n

struct<\/span> ContentView: View<\/span> {\n    var<\/span> body: some<\/span> View<\/span> {\n        Text<\/span>(\"Hello, world!\"<\/span>)\n            .padding<\/span>()\n            .foregroundStyle<\/span>(.blue<\/span>)\n            .font<\/span>(.headline<\/span>)\n    }\n}<\/code><\/pre>\n
When using the some<\/code> keyword, the compiler will infer the underlying concrete type that\u2019s actually being returned, which is especially helpful when working with APIs that heavily utilize generics \u2014 such as SwiftUI. Without some<\/code>, we\u2019d have to always manually specify the concrete type of our entire view hierarchy, which even in the case of the above (very simple) ContentView<\/code> is as complex as this:<\/p>\n
ModifiedContent<\/span><ModifiedContent<\/span><ModifiedContent<\/span><Text<\/span>,\n_PaddingLayout<\/span>>, _ForegroundStyleModifier<\/span><Color<\/span>>>,\n_EnvironmentKeyWritingModifier<\/span><Optional<\/span><Font<\/span>>>><\/code><\/pre>\n
But the some<\/code> keyword isn\u2019t just<\/em> useful when working with SwiftUI. In fact, we can use it to solve similar generics-based problems, and as syntactic sugar, across a wide range of use cases.<\/p>\n
Generic function parameters<\/h2>\n
Let\u2019s say that we\u2019re working on a video watching app, and that our app\u2019s Database<\/code> type contains an API for saving a set of videos to the user\u2019s \u201cwatch later\u201d<\/em> list:<\/p>\n
actor<\/span> Database {\n    ...\n\n    func<\/span> saveToWatchLater(_<\/span> videos: [Video<\/span>]) {\n        var<\/span> watchLater = loadWatchLater<\/span>()\n\n        for<\/span> video in<\/span> videos {\n            watchLater.addVideo<\/span>(withID: video.id<\/span>)\n        }\n\n        save<\/span>(watchLater)\n    }\n}<\/code><\/pre>\n
Currently, our API only accepts arrays of Video<\/code> values, but across our app, videos might be stored using different kinds of collections \u2014 including sets, dictionaries, and perhaps custom collections\/sequences as well. So, to make our saveToWatchLater<\/code> API a bit more generic<\/em> we could, well, actually make it generic:<\/p>\n
actor<\/span> Database {\n    ...\n\n    func<\/span> saveToWatchLater<T: Sequence<\/span>>(_<\/span> videos: T<\/span>) where<\/span> T<\/span>.Element<\/span> == Video<\/span> {\n        ...\n    }\n}<\/code><\/pre>\n
That works, but it does arguably add a bit of complexity to our function declaration. This is where the some<\/code> keyword comes in, which \u2014 just like when using SwiftUI \u2014 can help us avoid some of the complexity involved in working with generics. In this case, we can use it to be able to reference the Sequence<\/code> protocol directly, which works since that protocol marks its associated Element<\/code> type as its primary associated type<\/em>.<\/p>\n
actor<\/span> Database {\n    ...\n\n    func<\/span> saveToWatchLater(_<\/span> videos: some<\/span> Sequence<\/span><Video<\/span>>) {\n        ...\n    }\n}<\/code><\/pre>\n
With that, we\u2019ve ended up with a quite simple solution that still lets us leverage the power and flexibility that generics offer, all without introducing any kind of type erasure or runtime overhead.<\/p>\n
An alternative to type erasure or boxing<\/h2>\n
Speaking of type erasure, the some<\/code> keyword can also help us avoid having to perform type erasure, or otherwise box a given value or object into something that needs to be resolved at runtime (which tends to add both complexity and overhead).<\/p>\n
For example, let\u2019s say that we\u2019re structuring various async operations across our app using an Operation<\/code> protocol, which in turn emits OperationEvent<\/code> values when performed \u2014 sort of like a lightweight, less complex version of something like a Combine publisher:<\/p>\n
enum<\/span> OperationEvent<Output> {\n    case<\/span> progressUpdate(completionRatio: Double<\/span>)\n    case<\/span> finished(Output<\/span>)\n    case<\/span> failed(Error<\/span>)\n}\n\nprotocol<\/span> Operation<Output> {\n    associatedtype<\/span> Output\n    typealias<\/span> EventStream = AsyncStream<\/span><OperationEvent<\/span><Output<\/span>>>\n\n    func<\/span> perform() -> EventStream<\/span>\n}<\/code><\/pre>\n
\n
Our Operation<\/code> protocol declares its Output<\/code> type as its primary associated type, using the same syntax as concrete types use when declaring their generic type lists.<\/p>\n<\/blockquote>\n
One way of using the above protocol, for example in order to implement upload and download networking operations, would be to have our various APIs return concrete, Operation<\/code>-conforming types that\u2019ll become known to each call site:<\/p>\n
actor<\/span> NetworkService {\n    ...\n\n    func<\/span> downloadOperation(for url: URL<\/span>) -> DownloadOperation<\/span> {\n        DownloadOperation<\/span>(url: url, service: self<\/span>)\n    }\n\n    func<\/span> uploadOperation(for upload: Upload<\/span>) -> UploadOperation<\/span> {\n        UploadOperation<\/span>(upload: upload, service: self<\/span>)\n    }\n}<\/code><\/pre>\n
The above works, but it does arguably expose a bit too many implementation details to the caller. For example, if the above NetworkService<\/code> would be part of a Swift Package\u2019s public API, then we\u2019d have to also make all return types (such as DownloadOperation<\/code> and UploadOperation<\/code>) public as well, which we might not want to do.<\/p>\n
Ideally, we might want to make all operation implementations private, which would give our NetworkService<\/code> a much simpler and clearer API design, for example using a setup like this:<\/p>\n
private extension<\/span> NetworkService<\/span> {\n    struct<\/span> DownloadOperation: Operation<\/span><Data<\/span>> {\n        var<\/span> url: URL<\/span>\n        var<\/span> service: NetworkService<\/span>\n\n        func<\/span> perform() -> EventStream<\/span> {\n            ...\n        }\n    }\n\n    struct<\/span> UploadOperation: Operation<\/span><Void<\/span>> {\n        var<\/span> upload: Upload<\/span>\n        var<\/span> service: NetworkService<\/span>\n\n        func<\/span> perform() -> EventStream<\/span> {\n            ...\n        }\n    }\n}<\/code><\/pre>\n
However, the above change does present us with a problem \u2014 what are we supposed to return from our various operation-building functions? This is a case where, historically, type erasure has often been used, to enable us to return an opaque wrapper that boxes our underlying implementation\u2019s actual logic. In this case, we could make such a wrapper capture the underlying type\u2019s perform<\/code> method as a closure:<\/p>\n
struct<\/span> AnyOperation<Output>: Operation<\/span><Output<\/span>> {\n    var<\/span> performer: () -> EventStream<\/span>\n\n    func<\/span> perform() -> EventStream<\/span> {\n        performer<\/span>()\n    }\n}\n\nactor<\/span> NetworkService {\n    ...\n\n    func<\/span> downloadOperation(for url: URL<\/span>) -> AnyOperation<\/span><Data<\/span>> {\n        let<\/span> operation = DownloadOperation<\/span>(url: url, service: self<\/span>)\n        return<\/span> AnyOperation<\/span>(performer: operation.perform<\/span>)\n    }\n\n    func<\/span> uploadOperation(for upload: Upload<\/span>) -> AnyOperation<\/span><Void<\/span>> {\n        let<\/span> operation = UploadOperation<\/span>(upload: upload, service: self<\/span>)\n        return<\/span> AnyOperation<\/span>(performer: operation.perform<\/span>)\n    }\n}<\/code><\/pre>\n
This is another case where the some<\/code> keyword can really help us simplify things. Instead of having to manually do type erasure, we can achieve the same kind of separation of concerns and clean API design simply by having each of our operation-building functions return some Operation<\/code>, specialized with the type of value that each operation produces \u2014 like this:<\/p>\n
actor<\/span> NetworkService {\n    ...\n\n    func<\/span> downloadOperation(for url: URL<\/span>) -> some<\/span> Operation<\/span><Data<\/span>> {\n        DownloadOperation<\/span>(url: url, service: self<\/span>)\n    }\n\n    func<\/span> uploadOperation(for upload: Upload<\/span>) -> some<\/span> Operation<\/span><Void<\/span>> {\n        UploadOperation<\/span>(upload: upload, service: self<\/span>)\n    }\n}<\/code><\/pre>\n
Much simpler, and again, without introducing additional runtime overhead, since types annotated with the some<\/code> keyword are always resolved at compile time. That\u2019s one of the key differences between this solution compared to if we instead would\u2019ve chosen to use the any<\/code> keyword, which also lets us refer to a generic protocol as a type, but with the important difference that it boxes the underlying value into a so-called existential<\/em>, which needs to be unboxed and resolved at runtime.<\/p>\n
That of course doesn\u2019t mean that the any<\/code> keyword is just a worse version of some<\/code> \u2014 existentials have their use cases too, which we\u2019ll take a closer look at in future articles.<\/p>\n
Conclusion<\/h2>\n
When certain Swift features are prominently used within a specific framework or domain, it can be easy to think of such a feature as just a tool for that specific task \u2014 as is often the case with the some<\/code> keyword and SwiftUI. But hopefully this article has illustrated that some<\/code> is an incredibly useful feature that can be used to reduce complexity when working with all sorts of generics, and to create very neat APIs that cleanly abstract their implementation details from their call sites. All without sacrificing performance or introducing additional runtime logic.<\/p>\n
Thanks for reading!<\/p>","protected":false},"excerpt":{"rendered":"
Developers who have worked with Apple\u2019s SwiftUI framework have likely encountered the some keyword in the context of defining custom views, where it\u2019s typically used to enable the generic View protocol to be referenced as a type when declaring a view\u2019s body: struct ContentView: View { var body: some View { Text(“Hello, world!”) .padding() .foregroundStyle(.blue) […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rop_custom_images_group":[],"rop_custom_messages_group":[],"rop_publish_now":"initial","rop_publish_now_accounts":[],"rop_publish_now_history":[],"rop_publish_now_status":"pending","footnotes":""},"categories":[1],"tags":[],"class_list":["post-12821","post","type-post","status-publish","format-standard","hentry","category-explore"],"_links":{"self":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/12821","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/comments?post=12821"}],"version-history":[{"count":0,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/12821\/revisions"}],"wp:attachment":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/media?parent=12821"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/categories?post=12821"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/tags?post=12821"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}