[Discussion] Eliding `some` in Swift 6

[tabsandspaces]

@GreatApe

@hborla

On the other hand, I think one of Swift's biggest criticisms is the compiler "nagging" programmers about things they got wrong in their code that are actually harmless, and having to make minor changes to code "just to appease the compiler".

Yes I often hear this criticism, probably mostly from old web developers and objective c veterans, but I never understood it.

@GreatApe

@hborla

If it is indeed true that in Swift, parametric polymorphism is more often the better tool for the job than subtype polymorphism, then some might become just another one of those annoying things you need to write in your code to appease the compiler.

This is not quite how I see it. For me it's not about marking a particular type of polymorphism, the reason it makes sense to have a keyword in front of P is simply that the function doesn't actually return P . It returns something that is related to P , but not "a P ", because that doesn't make sense.

I agree. Changing from a bare protocol to using some is not merely making a minor boilerplate change to appease the compiler. It makes an important difference to the meaning of the code, which the developer (and others working on the codebase with them, or using the APIs they vend) should be able to observe. I don't think the argument that some is closer in meaning to the bare protocol than any is to the bare protocol is strong enough to justify routinely eliding some. They may be closer in meaning, but that is not a reason for them to have the same syntax.

I also agree with the other comments about protocol extensions. The fact that extension P has the unclear behaviour that it does shouldn't be an argument for doing it here too.

Seeing recent code examples with explicit use of some and any everywhere where they apply is one of the few times in my programming career where I've caught myself thinking "wow, I really like this language design choice". I would be sad to see it go away. Consistently providing the vocabulary to reason about use of some P or any P feels much more useful, and safer, than the alternative.

@hborla

Pre-5.7, I'd received a lot of feedback that people don't know what some really means and they just stick it into their SwiftUI views to satisfy the compiler.

I had similar thoughts, and that's exactly why I think it would be a huge mistake to elide some. When I started working with SwiftUI and coming across some View, that was the only place I could recall seeing that construct, so I just used it without really understanding what the code was doing. I didn't really understand the SwiftUI-related discussions of type erasure either. But with only a few minutes learning about some and any from WWDC, that confusion is totally gone. Hiding this complexity out of concern that newcomers may misunderstand may accomplish the exact opposite of your goal. Developers will be hindered in coming to a full understanding of the code they write.

Tricking people into writing generic code without realising what they're doing doesn't seem like a useful goal. I am not necessarily fundamentally opposed to eliding some, but I remain unconvinced that the reasoning outlined here justifies it, or that it would not cause more problems than it solves.