some and any keyword in Swift

How many times have you encountered the following compilation error:

Protocol ‘Type’ can only be used as a generic constraint because it has Self or associated type requirements

…….. I have, a lot !

Swift 5.7 introduced 2 new keywords: some and any that helps us get rid of this error in the most neat manner

I meant neat manner because prior to Swift 5.7, we could have gotten rid of that error without the use of some and any using generics:

However, if you want to create a computed property that returns a generic type like above (the one that worked without some keyword), you cannot use the mechanism defined above:

Although, if you really want to use the mechanism specified above (that did not work due to compilation error), you'll have to create a generic struct and use that generic as return type for the computed property. That might make sense in some cases but that might be an overkill if you ask me since that job can easily be done by some keyword

But as you dive deep into generics with Protocols, you’ll realise some and any are the syntactic sugar that we needed all this time

The main focus of this article is to explain both these keywords through similarities and differences between them. I will be using one of SwiftUI’s protocol View whose declaration primarily looks like:

Similarities

Both some and any can be used with Protocol that have associatedtype in it (also called as generic protocols)

Consider the following example:

Reasons for the above:

1. Compilation failed since View has associatedtype Body: View inside it

2. Compilation succeeds since now we have declared the type with some keyword which acts as opaque type

3. Compilation succeeds since now we have declared the type with any keyword which acts as existential type

Differences

The real fun starts when you look at the actual differences between the two of them since above code does not clearly states which should be used when

Homogeneous vs Heterogeneous collection behaviour

some only allows homogeneous collection, meaning only similar conforming type are allowed inside the collection. Meanwhile any allows heterogeneous collection meaning any conforming type is allowed inside the collection

Consider the following example:

Reasons for the above:

1. Compilation succeeds since all the View’s conforming type that are being added to the collection are of same type; and some is good with that 😎

2. Compilation failed since now we have 2 different conforming types inside the same collection; some gets angry 😤

3. Compilation succeeds since any is unbothered whether or not the conforming types that are being added to the collection are of same type or not 😴

Similar return type

some only allows same conforming type to be returned; any however is generous and allows any conforming type to be returned

Consider the following example:

Reasons for the above:

1. Compilation succeeds since we’ll always be returning the same conforming type irrespective of the value of random at runtime; some approves of it 👍

2. Compilation failed since now different conforming types are being returned; some rejects it 👎

3. Compilation succeeds since any is unbothered whether or not we’re returning same or different conforming types; typical any 🥱

Now that we are done with the similarities and differences, it’s time for the verdict:

You should always start with some keyword first and if that does not fit your generics use case, switch to any keyword

That is because any relies on a mechanism in programming language called Type Erasure which essentially hides specific type information from code that doesn’t need to concern itself with those types. I won’t be covering that here since that will just add lengths to the article. But you should definitely read about it

That’s it, folks! Happy Coding!