[Pitch] Light-weight same-type constraint syntax

[DevAndArtist (Adrian Meister)]

@jrose

I'm not yet convinced that "we're gonna want 'em" in Swift, but it's true that if we did add them, this would be the syntax people would expect, and if we took this proposal and then added generic protocols, we'd have some protocols you could conform to in multiple ways and some you couldn't.

Well this is exactly why I'm worried about this proposal and why I previously said that we're trying to jump over too many hoops at once. This proposal is additive but not incremental at all.

The community and the core team already explored the next steps in depth:

1. unlocking the where clause in typealiases
2. improving the UX with "one" possible, but unambiguous spelling such as P<.Assoc == T>

It won't kill anyone to start with (1), as it's purely incremental add-on. (2) is just "one" option to improve upon (1). However the proposal to me reads like (2) was already too much for the users to deal with and we need to improve even further. Excuse me, with all my respect, please give us at least (1) so we can start using the actual feature in question and not elaborate on how to improve with sugar code (proposal) over other hypothetical non-existing sugar code (2).

---

I'm sorry to bring this up again, but I have this quote stuck in my mind from @Chris_Lattner3 for similar sugar proposals:

@Chris_Lattner

Beyond that, though syntactic sugar is always motivated by strong rationale and use-cases, in my opinion, it is the most dangerous kind of additive feature to consider at this point of Swift’s evolution. While these features are useful, they also clearly add complexity to the language, and it is difficult to gauge whether the problem being addressed will even exist in Swift as the other bigger features come in (for example, a macro system). These features can also make future language evolution more problematic because they consume syntactic real estate in the language.

If you’re into analogies, I see features like the generics improvements, ownership model, concurrency model, macro system, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift. In that analogy, syntactic sugar proposals are “mortar” that fills in the cracks between the bricks. If we add too much mortar too early on, we run the risk of the house of Swift being built out of mortar, or of not being able to fit the bricks into the right places. That would be very bad, given that we all want the house of Swift to be strong and beautiful over the long term.