[Pitch] Elide `some` in Swift 6

[tabsandspaces]

-1 from me.

@angela-laar

Generic code is already simplified in more places than you think. Take protocol extensions, for example. To write generic code applicable to any concrete type conforming to a protocol, you only need to write the extension keyword and the plain protocol name.

Having already made inadvertent mistakes in language design is not a reasonable argument for knowingly making more.

@angela-laar

Deciding to introduce a protocol into your code to allow for more abstraction should be considered a separate decision and this proposal would decouple those two decisions.

I may be misunderstanding here, but to me it seems like it wouldn't decouple the decisions, it would make the second decision for you automatically without telling you.

@angela-laar

I wouldn't say making bare protocols is really "making the language more opaque" though. Instead this proposal is improving the language design in such a way that enhances user experience;

As I've mentioned before, my experience is precisely the opposite. I was totally unable to form a proper understanding of generics in Swift prior to seeing code that consistently used explicit some.

@tabsandspaces

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.

[...]

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.

@angela-laar

Why require users who want to add abstraction to their code using protocols to deep dive into the semantic differences?

The alternative is that people will be writing a lot of code that they do not truly understand. Languages must not hide important semantic differences from code authors just because they think they know what the author probably "really" means.

In my opinion, this pitch has no benefits, only a number of known costs and fairly significant risks.