[swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

[Rod Brown]

> What I'm saying is that I strongly prefer this:
> 
>    func print(_ values: Any..., separator: String, terminator: String)
> 
> To this:
> 
>    func print(_ values: any..., separator: String, terminator: String)
> 
> And that I think it would be confusing and unnecessarily duplicative to have both `Any` and `any<...>` in the language, differing only in capitalization.

I agree personally. The way I see it, Any<> refers to the type, which should be upper camel case.

> No—what I'm saying is that, in a choice between `Any<Sequence>` and `any<Sequence>`, I would prefer to use `Any<Sequence>`. The `Any<…>` here is acting like a type (actually, it *is* a type, just a slightly special type) and it should be capitalized like a type.

Yep, you hit the nail on the head. Exactly right.

> This is quite the opposite of what I would want—I would much prefer that people use `Any<Sequence>` directly rather than an `AnySequence` typedef. This will help them learn that the feature is there for other situations, like `Any<Equatable>`.

Agreed. Any<> is an extensible construct. AnySequence is not.

> In general, I believe it's a good idea to expose `Any<…>` directly, rather than hiding it behind a typealias. For the cost of a few extra characters, we expose a lot of power and flexibility directly to the user. For instance, if you see `Any<Collection where .Element == String>`, it's a small step to realize that you could also say `Any<Collection where .Index == Int>`. If you're always using `AnyCollection<String>`, on the other hand, you may never figure that out.

- Rod