[Pitch] Elide `some` in Swift 6

[johnno1962 (John Holdsworth)]

@Zollerboy1

@johnno1962

Leaving aside questions about whether we want to design the language around people who don't use Xcode

Considering the amount of time and effort I've spent over the last years trying to convince people that Swift can in fact be used for other things besides iOS programming, it makes me sad to hear this sentence.

I apologise for that throw-away comment. I myself provided a toolchain for Android for a while and have high hopes for Swift on the server if we can solve this problem. I’m going to try really hard to make this my last post on this topic as I’m sure practically no-one can be under any illusions on my stance.

@Zollerboy1

Regarding the ongoing discussion about having a bare protocol mean some in most cases but any in some special cases:

I’m not quite saying that. I’ve a evaluated few things and the most effective rule is elide to some only in some specific cases and any for everything else. If this pitch is to "just elide to some" qualitatively that seems to almost make migration disruption worse not better and it defeats itself.

Looking again at Gwedall’s big diff where he conscientiously went through and tried to do he right thing. The new explicit annotations are almost completly divided between some for arguments (407) and any for everything else (293) which I believe is easy enough to understand and elide. It’s handy this coincides with the engineering win of finally setting right the historical accident that existentials where ever used by default for passing things around. I do feel we should elide to something though if only for the library maintainers as otherwise we are going to create a “language schism” where the net effect of Swift 6 coming out may be library maintainers adding an explicit language version of 5 to their packages and dooming those supporting the compiler to supporting language version 5 for quite some time.

Anyway, I’m going to leave this debate with a pointer to my first naive thoughts a couple of years ago. I find it ironic that my last thoughts align so closely with my initial gut intuition.

Introduction of new keyword 'any' for protocol conforming arguments

SE-0335 has been accepted and on it’s current trajectory will eventually impose a source breaking change to the Swift language where any methods that have argument types which are a protocol will need to be rewritten to prefix the protocol name with a new keyword any. The review breezed through and this is on all our horizons and already available in Xcode 13.3. The specifics of the change are rather long winded and revolves around the overhead associated with the use of “existential containers…

If I’ve learned anything in IT (and that's always been subject to debate ) it's that the only allies you have in one's own personal "rage against the machine” as a programmer are simplicity and stability. SE-0335 always went against both those tenants for me.

Edit:
I don't want this last comment to sound like a glib manifesto against trying to improve things or change in general. It's just sometimes you need to take smaller steps so everybody gets to keep up. Selecting a more pragmatic form of eliding would seem to be the appropriate next step which is why I support this pitch. It will take some of the sting out of the changes to come.