This is an interesting example of emotional frustration pretending to be a technical argument. I'm fascinated by the mechanics of irrational hype and subjective downward spirals of dissatisfaction on technical topics. It's very similar to how many people consider the best music of all time to be the one made by their own generation or what they grew up with through their parents. Most of us are employed by building more and better options and features, but as a community there is a streak of what I call cranky senior developer that is just tired of all the new features and would like it tear it all down. You can also call it "complexity fatigue".
I don't use Swift full time and I had no problem reading that method signature.
This is something that you would write if you were a library author interested in providing generic and flexible data structure. The part after "where" expresses a non-trivial idea: "the type of the first element parameter should be the same as the inner element of the homogenous collection (second parameter), and we need to compare elements to other instances of its type but other than those constraints this code will work on any element and collection". It does that in about 6 swift terms, and the compiler has a full understanding of what you meant and will prevent errors that violate these constraints. Notice that you never have to write this type of code if you're using the library. Swift has decently organized progressive disclosure of language features. For example I never had to write unsafe pointer arithmetic or interop with C, but I'm not going to complain the feature is there for those that need it.
I don't use Swift full time and I had no problem reading that method signature.
This is something that you would write if you were a library author interested in providing generic and flexible data structure. The part after "where" expresses a non-trivial idea: "the type of the first element parameter should be the same as the inner element of the homogenous collection (second parameter), and we need to compare elements to other instances of its type but other than those constraints this code will work on any element and collection". It does that in about 6 swift terms, and the compiler has a full understanding of what you meant and will prevent errors that violate these constraints. Notice that you never have to write this type of code if you're using the library. Swift has decently organized progressive disclosure of language features. For example I never had to write unsafe pointer arithmetic or interop with C, but I'm not going to complain the feature is there for those that need it.