[Pitch] Light-weight same-type constraint syntax

[Jumhyn (Frederick Kellison-Linn)]

@Karl

When you step back and look at it, we chop up the information about generic types and scatter it about the function signature like we're almost trying to hide it. Deciphering a generic function is a lot more convoluted than your typical, non-generic function, and information locality is a big reason for it, IMO.

Without straying too far from the pitch at hand, I just want to say I agree wholeheartedly with this sentiment. I think I have a pretty strong mental model that separates each generic parameter's 'primary' constraints (those that don't reference any other generic parameters) from its 'secondary' constraints (those that reference other generic parameters). IMO, it would be great to be able to specify the 'primary' constraints up front to avoid the back-and-forth kind of reading that you note.

@filip-sakel

Existentials are constantly being confused with generics. Many beginners don't understand the difference between func f(_: Numeric) and f<T: Numeric>(_: T) — I too was oblivious to it for a long time. Even now, people unknowingly refer to Collection or arithmetic-protocol existentials, unknowingly incurring significant performance penalties.

Do we have an idea of how common these problematic uses of existentials are? I have been under the impression for some time that many uses of existentials are isomorphic to the equivalent generic signature, and shouldn't incur any performance or optimization penalty.