<html><body><div>Am 25. Mai 2016 um 10:01 schrieb Austin Zheng via swift-evolution <swift-evolution@swift.org>:<br><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">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.<br><br><blockquote type="cite" class="quoted-plain-text">On May 25, 2016, at 12:34 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"><blockquote type="cite" class="quoted-plain-text"> * What is your evaluation of the proposal?</blockquote></blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">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.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">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.</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">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:</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"> let printable: CustomStringConvertible = foo</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text">Would now be written:</blockquote><blockquote type="cite" class="quoted-plain-text"><br></blockquote><blockquote type="cite" class="quoted-plain-text"> let printable: Any<CustomStringConvertible> = foo</blockquote><br>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.</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>AFAIK an existential type is a type T with type parameters that are still abstract (see for example <a href="https://en.wikipedia.org/wiki/Type_system#Existential_types)">https://en.wikipedia.org/wiki/Type_system#Existential_types</a>), i.e. have not been assigned concrete values.</span></div><div><span><br data-mce-bogus="1"></span></div><div><span>In Swift these are protocols with Self type requirements (which are always varying) or with associated types that haven't been assigned, yet.<br data-mce-bogus="1"></span></div><div><span>These currently cannot be used in type declarations but will be usable with Any<...><br data-mce-bogus="1"></span></div><div><span><br data-mce-bogus="1"></span></div><div><span>Other protocols which do not have Self type requirements or associated types are *not* existential types.<br data-mce-bogus="1"></span></div><div><span>`CustomStringConvertible` in particular which is used in the example is *not* an existential type and therefore should still be usable as:<br data-mce-bogus="1"></span></div><div><span><br data-mce-bogus="1"></span></div><div><span>let printable: CustomStringConvertible = foo </span></div><div><span><br data-mce-bogus="1"></span></div><div><span>i.e. it would *not* be required to write Any<CustomStringConvertible> because CustomStringConvertible is not an existential type.<br data-mce-bogus="1"></span></div><div><span><br data-mce-bogus="1"></span></div><div><span>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.<br data-mce-bogus="1"></span></div><div><span><br data-mce-bogus="1"></span></div><div><span>-Thorsten<br data-mce-bogus="1"></span></div><br data-mce-bogus="1"></div></body></html>