This is the one argument I think really holds water against what I've suggested, and I've been waiting for someone to make it; sorry I missed your previous mention. My best answer is that I think the unconstrained existential is special. I think it's a serious problem that you can have a type called, simply, SomeProtocol and go look at the declaration of that type, and not be able to access some part of the API declared there. If it were spelled “SomeProtocol where _”, then I'd probably be more comfortable with some of the protocol's API being implicitly unavailable, because there's this attached “where I don't know anything other than that the type conforms” right there in the code.
Generalized existentials are an extremely powerful feature that includes a nontrivial amount of essential complexity. Learning how to work with them will necessarily involve some effort. I don't see any way around this.
I don't think this means we should not support the feature or be afraid that users won't be able to use it effectively (one thing I love about Swift is that it has mostly avoided that kind of paternalism). I think it means we need put more effort than usual into educating people about this feature, how to use it well, and what pitfalls or traps they to be aware of. This is especially necessary as generalized existentials is a relatively sophisticated feature for which I don't think there is a clear point of reference in the previous experience of most programmers.
Agreed 100%. Precisely because the feature “includes a nontrivial amount of essential complexity,” we need to be careful about how we introduce it, how it will interact in users' minds with the rest of the language, whether we're putting that complexity in too close at hand when features with fewer pitfalls are farther away, and what new problems arise when we introduce part, but not all, of the feature.