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

[Rod Brown via swift-evolution]

> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution