[Pitch 2] Light-weight same-type requirement syntax

[Karl]

@gwendal.roue

This cliff creates two different problems:

1. Developers who aren't familiar with generics (the targets of the simplified syntaxes). They don't even know where to start from . The full syntax is not derived from the simplified syntax.
2. Developers who are familiar with generics. They feel fatigue when they know they have to rewrite their function signature (or protocol declaration). It is boring, and it is possible to make a mistake.

Very quickly speaking, and not wanting to pretend I know what's inside their minds, it looks like @Karl is talking about problem 2, when @hborla may like to address problem 1.

I don't think so; as far as I'm concerned, I'm (intending) to talk about both.

Whenever I learn a new programming language or concept, I start with basic examples, then I play around with them and add things, applying the rules until I develop an intuitive understanding of how things work. I think that's a very general thing.

The problem with this design is that you can't do that. As I've shown - want to add some collection indexes to a Dictionary or Set? Then you start needing to rewrite the function signature in a dramatic way and everything starts to fall apart.

Not only does that not help, I actually think it hurts. It makes you feel like adding a Index: Hashable requirement is some super-advanced concept that should only be attempted by rocket scientists. It's so painful that it acts as a disincentive to learn about other things.

--

Also, one thing I find a bit irritating: it isn't just Holly who cares that generics are approachable and learnable - I've also been mentioning it and offering ideas for years.

For example, back when the idea was that we needed "partial protocols" or "existential self-conformance" to make our generics system flow better, I set out what I thought the issues were.

• That existential syntax was too simple, and too easy to confuse with generics
• That the compiler would automatically box types in to existentials, but not automatically open them

And that these combined to make generics difficult to understand.

Lifting the "Self or associated type" constraint on existentials

This topic seems to have gained some traction across a couple of threads, so I felt like writing out my opinion on where I think existentials should go in Swift in one place. I'd really like us to remove this restriction, but more broadly, I think we need to drastically cut ("focus") what you can do with existentials, deprecate certain uses, and revise the syntax. Summary: Existentials have only 2 real use-cases: storage of an erased value, and inout function parameters which may assign the ob…

Maybe others had mentioned some of these issues before, but I've been active on the forums since they started, and I'd never seen them expressed in that way in that context. Those were original thoughts, and I took the time to write them up, and the risk to express them in an open forum. The reactions at the time seemed to suggest they were not obvious comments.

Now those things are coming in to the language - which is great! I'm not acknowledged as contributing towards any of those features, of course.

I don't participate in these forums to chase acknowledgement and I would never ask for it, but in the context of your post and the points that you're making, I would like to draw attention to the fact that I do very much care about making generics learnable. I'm not only interested in advanced use-cases.

But that's all I'd like to say on that subject. Again, I don't ask for acknowledgement and find it a bit embarrassing to even talk about it.