Am 25. Mai 2016 um 10:01 schrieb Austin Zheng via swift-evolution <[email protected]>:
I am not going to comment on the proposal (conflict of interest etc). I do want to speak up in support of Brent's points, though. On May 25, 2016, at 12:34 AM, Brent Royal-Gordon via swift-evolution <[email protected]> wrote: * What is your evaluation of the proposal? I am in favor. This is a necessary step towards many future features: class-plus-protocol types, the replacement/reimplementation of AnyObject with Any<class>, existentials with associated types, etc. One reason to prefer `Any` over `any` which is not listed in the proposal is confusion with the unparameterized `Any` type. Having an uppercase `Any` and a lowercase `any<…>` is going to lead to a lot of confusion; people aren't going to remember whether they need the capitalized form or the lowercase one for any particular use. I don't think we can have `any<...>` unless we're also willing to have an unparameterized `any`, and I think `any` is 100% wrong, because it is absolutely a type but is lowercase. Since we are trying to cram as many breaking changes as possible into Swift 3, I also think we should consider now, or soon, whether or not we want to draw a strong syntactic line between protocols-as-existentials and protocols-as-constraints by requiring the use of `Any<…>` on all existentials and forbidding its use in constraints. That would mean, for instance, that code like this: let printable: CustomStringConvertible = foo Would now be written: let printable: Any<CustomStringConvertible> = foo I'm sure this will be controversial, but I like the idea of marking all existential types using Any-syntax. It makes the distinction between concrete and existential types in code completely clear to the reader. Given that there are some subtle differences in how concrete and existential types can be used (for example, used as the types of values passed to generic functions), I think this is definitely worth considering. AFAIK an existential type is a type T with type parameters that are still abstract (see for example https://en.wikipedia.org/wiki/Type_system#Existential_types), i.e. have not been assigned concrete values. In Swift these are protocols with Self type requirements (which are always varying) or with associated types that haven't been assigned, yet. These currently cannot be used in type declarations but will be usable with Any<...> Other protocols which do not have Self type requirements or associated types are *not* existential types. `CustomStringConvertible` in particular which is used in the example is *not* an existential type and therefore should still be usable as: let printable: CustomStringConvertible = foo i.e. it would *not* be required to write Any<CustomStringConvertible> because CustomStringConvertible is not an existential type. While I would love making existential types available at last in Swift with this proposal I will not support requiring all protocols to be written as existentials. This makes no sense. -Thorsten
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
