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

[Matthew Johnson]

> On May 20, 2016, at 8:29 PM, Rod Brown <rodney.brown6 at icloud.com> wrote:
> 
> 
> 
> 
>> 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.

If `any` could be used in all of the same ways as a generic type I would agree.  But it can’t.  I think making it look like a generic type would be confusing to new users.

> 
>> 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