<html><body><div><br></div><div><br>Am 25. Mai 2016 um 09:34 schrieb Brent Royal-Gordon 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"><blockquote type="cite" class="quoted-plain-text"> * What is your evaluation of the proposal?</blockquote><br>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.<br><br>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.<br><br>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:<br><br> let printable: CustomStringConvertible = foo<br><br>Would now be written:<br><br> let printable: Any<CustomStringConvertible> = foo<br><br>And also that code like:<br><br> func foo<X: Any<Y, Z>>(x: X)<br><br>Would probably have to be written something like:<br><br> func foo<X: Y>(x: X) where X: Z</span></div></div></blockquote></div><div><span><br data-mce-bogus="1"></span></div><div><span>Although I am strictly against having to write non-existential protocols as existentials (as I have written in another post), I also think that it would be desirable to use existentials only for declaring types of variables or parameters etc. but not for defining constraints, i.e.</span></div><div><span><br data-mce-bogus="1"></span></div><div><span><span class="body-text-content">let printable: CustomStringConvertible = foo</span> // fine, <span class="body-text-content">CustomStringConvertible is not an existential</span><br></span></div><div><span><span class="body-text-content">let coll: any<Collection> // allowed usage of existential<br data-mce-bogus="1"></span></span></div><div><span><span class="body-text-content">func foo<X>(x: X) where X: Y, Z // existential any<Y, Z> not allowed here<br data-mce-bogus="1"></span></span></div><div><span><span class="body-text-content"><br data-mce-bogus="1"></span></span></div><div><span><span class="body-text-content">-Thorsten<br data-mce-bogus="1"></span></span></div><div><span><span class="body-text-content"><br data-mce-bogus="1"></span></span></div><div><span><span class="body-text-content"><br data-mce-bogus="1"></span></span></div><div><span><br></span><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><br><br>However, I believe this would have a significant advantage: it would clarify the distinction between an existential and a constraint. It would more clearly mark where you are taking on the abstraction overhead of an existential. It would also improve the non-existential type situation: in the short term, it would make it clearer where uses of associated type protocols like `Comparable` would not be permitted; in the long term, once we have type-erased existentials for those protocols, it would make it clearer when type erasure was in effect.<br><br><blockquote type="cite" class="quoted-plain-text"> * Is the problem being addressed significant enough to warrant a change to Swift?</blockquote><br>Yes. `protocol<>` is an ugly and unloved corner of the language; very few people know about it, remember it, or use it. The renaming improves this situation.<br><br><blockquote type="cite" class="quoted-plain-text"> * Does this proposal fit well with the feel and direction of Swift?</blockquote><br>Given the way it enables many future features, yes.<br><br><blockquote type="cite" class="quoted-plain-text"> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</blockquote><br>The only language I've used with similar features is Objective-C. There, too, the `<>` is overloaded, now that lightweight generics are part of the language.<br><br><blockquote type="cite" class="quoted-plain-text"> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</blockquote><br>I'd like to think I have a fairly deep understanding of this feature, having participated heavily in the discussions about it.<br><br>-- <br>Brent Royal-Gordon<br>Architechies<br><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></div></blockquote></div></div></body></html>