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

[Karl]

@hborla

We can't possibly name every contributor in the "acknowledgments" section of proposals, because there are so many valuable contributors participating in these discussions and advocating for specific language features that they believe will help accomplish the goal. I hope this goes without saying, but I value all of the perspectives in this discussion and the ones that preceded.

I'm not suggesting otherwise - although I do hope proposal authors make more effort in future to acknowledge the time and effort volunteered by the community.

But that's all I'll say on it. It's a comment on another comment, not the point of the thread.

@Ben_Cohen

This is not to say that arbitrary constraints on opaque result types aren’t something we want to have. But the challenge is that the possible different syntaxes for them are not great. It is a hard problem to solve well and we should take our time with it. But it is also a feature that is neither urgent nor important. Constraining by a “primary” associated type on the other hand is both urgent and important. The lack of this feature is actually hampering real APIs every day.

This seems very arbitrary and hand-wavey. Unilateral declarations that some things are simply not important (despite plenty of feedback to the contrary in this thread) essentially shut down debate.

At the same time, I don't think this is an advanced feature, at all. It is a completely basic thing for a developer, just starting with their first generic collection function, to attempt to tag a Range<Index> using a dictionary or store indices in a Set. And what will they see?

@Karl

func doSomething(_ items: some Collection<Int>)

// Oh no! We need Index to conform to Hashable!
// It's just a simple matter of... oh...

func doSomething<C>(_ items: C) where C: Collection, C.Element == Int, C.Index: Hashable

Also, where was the community survey asking if the lack of constraints on opaque types were hampering our APIs? Because they certainly do. We also create "real APIs", you know ;)