[Discussion] Eliding `some` in Swift 6

[Jumhyn (Frederick Kellison-Linn)]

@GreatApe

On the other hand, if you mean that the distinction is not important because it will compile either way, just with a different meaning, then the arguments about "implicitly doing the right thing" fall flat, since you're then saying that it doesn't matter if people use any or some .

The version of the argument I find most compelling goes something like this:

1. Being able to treat protocols just like any other type would be very nice—users, particularly novice users, will likely instinctively write bare P as a first attempt as using a protocol as a type, and it would be nice if this worked out of the box
2. When bare P meant any P, the language was regrettably leading users down a design path (due to (1)) that had non-obvious consequences, and it was difficult to go back and change the decision to use existentials after they had been baked into many APIs.
   • Even with features like auto-opening, the language will not be able to just paper over all the distinctions between existentials and concrete types, as Ben mentions, and these distinctions matter.
   • This is the motivation for getting rid of the bare P <-> any P equivalence.
3. The difference between some P and any other 'normal' concrete type, is much smaller than the difference between any P and any other type.
   • IOW, if bare P means some P, users who use the default are less likely to run into issues down the line than they would be with any P, and when they do, those issues will matter less and be more easily fixable.
4. If we force users to specify some P or any P explicitly up front, we will be introducing a fair amount of friction in cases where the user could be blissfully ignorant of the fact that they're 'really' writing generic code.
   • Further, it will be difficult to explain to the user the distinction between some P and any P at the point of definition, before they have run into a concrete case where the difference matters.
5. So, because of (1) and (4), we'd like the 'bare' protocol syntax to have some meaning. (2) helped us clear up the syntax space for something other than existentials, and because of (3) we are not concerned that using the bare syntax for some P will have the same issues as any P.

Now, there's various assumptions here that would be good to validate empirically as we explore this direction, and I'm not totally satisfied that this argument sufficiently addresses concerns on the reading side of things, i.e., is it important when reading an API to understand up front that you're dealing with generic code as opposed to a concrete function? I'm not sure. But I think it's broadly true that some P is closer to 'just a normal type' than any P.