<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On May 25, 2016, at 5:03 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On May 25, 2016, at 9:59 AM, L. Mihalkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On May 25, 2016, at 10:01 AM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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 class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On May 25, 2016, at 12:34 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""> * What is your evaluation of the proposal?<br class=""></blockquote><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class=""> let printable: CustomStringConvertible = foo<br class=""><br class="">Would now be written:<br class=""><br class=""> let printable: Any<CustomStringConvertible> = foo<br class=""></blockquote><br class="">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.<br class=""><br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Much of what I read about the swift philosophy seems to boil down to immediate association of the semantic with the syntax, to help the newcomer 'parse' the language in their mind with less efforts. Seems to me that Any<> being so close to Array<> could be construed as running counter to that philosophy.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>This is a big part of the case for using lowercase `any`. But there are good arguments on both sides. In Joe’s hypothetical future Swift, `Any` would be a standard library type thus it wouldn’t have such a strong difference from Array.</div></div></div></blockquote><div><br></div><div>I was not referring to Any/Array. I was pointing out the rest of the expressions</div><div><br></div><div>Xxxxx<...> versus Yxxxxx<...></div><div><br></div><div>Might not be so easy to explain that despite the similarities of forms, these two expressions are vastly different. Flip side is: if this was scala, it would probably be at every yearly "Swift Days" conference in the "Swift puzzlers" session. :)</div><br><blockquote type="cite"><div><div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">There are an additional five characters (including two angle brackets to type), but I suspect bare existentials aren't used quite as often as concrete types are, so the aesthetic cost might not be too onerous.<br class=""><br class=""><blockquote type="cite" class=""><br class="">And also that code like:<br class=""><br class=""> func foo<X: Any<Y, Z>>(x: X)<br class=""><br class="">Would probably have to be written something like:<br class=""><br class=""> func foo<X: Y>(x: X) where X: Z<br class=""></blockquote><br class="">I also personally prefer this convention. The 'Any<Y, Z>' construct in the constraint above does not really have anything to do with existential types as they exist everywhere else in Swift; it simply means that whatever concrete type can be used to instantiate the function must conform to two different protocols.<br class=""><br class="">It's true that any concrete type that could be used to satisfy X in foo() could also be used to fill an Any<Y, Z> existential, but this correspondence isn't interesting to the user. The ways a user can use an Any<Y, Z> existential differ from the ways a sort-of-universal type like X in foo() can be used:<br class=""><br class="">// firstElement's type is known exactly at compile time, because X must be 'filled in'<br class="">// by a concrete type, and that concrete type's associated types are also known.<br class="">foo<X : Collection>(x: X) {<br class="">let firstElement : X.Iterator.Element = x.first!<br class="">}<br class=""><br class="">// firstElement's type is not ever known without some sort of dynamic downcasting,<br class="">// because the contract that defines the existential can guarantee nothing about its type.<br class="">let foo : <X : Collection> = ...<br class="">let firstElement : Any = x.first!<br class=""><br class=""><blockquote type="cite" class=""><br class="">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 class=""><br class=""><blockquote type="cite" class=""> * Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></blockquote><br class="">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 class=""><br class=""><blockquote type="cite" class=""> * Does this proposal fit well with the feel and direction of Swift?<br class=""></blockquote><br class="">Given the way it enables many future features, yes.<br class=""><br class=""><blockquote type="cite" class=""> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></blockquote><br class="">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 class=""><br class=""><blockquote type="cite" class=""> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></blockquote><br class="">I'd like to think I have a fairly deep understanding of this feature, having participated heavily in the discussions about it.<br class=""><br class="">--<span class="Apple-converted-space"> </span><br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></blockquote></body></html>