<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 17, 2016, at 1:52 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I put together the skeleton of a proposal detailing enhancements to how associated types can be referenced in Swift 3+. It's certainly not ready for submission, but I think it gets across my ideas pretty well. Would love to gather feedback and especially improvements.<div class=""><br class=""></div><div class="">Be unsparing; whatever form this feature takes will profoundly affect how Swift developers program for years, so it needs to be done right.<div class=""><br class=""></div><div class="">See below:</div><div class=""><br class=""></div><div class=""><b class="">Proposal</b></div><div class=""><br class=""></div><div class=""><div class="">An existential type is defined using the "Any<...>" construct. Existential types can be nested.</div><div class=""><br class=""></div><div class="">The empty existential type "Any<>" is typealiased to 'Any’.</div></div></div></div></div></blockquote><div><br class=""></div><div>Also, Any<SomeProtocol> is equivalent to SomeProtocol.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Within the angle brackets are zero or more 'clauses'. Clauses are separated by semicolons. (This is so commas can be used in where constraints, below. Better ideas are welcome. Maybe it's not necessary; we can use commas exclusively.)</div></div></div></div></div></blockquote><div><br class=""></div><div>I’m not a fan of the semicolon idea. I don’t see any reason for this. The `where` keyword separates the protocol list from the constraints just fine. The list on either side should be able to use commas with no problem (or line breaks if that proposal goes through).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">There are five different possible clauses:</div><div class=""><br class=""></div><div class=""><ul class=""><li class="">'class'. Must be the first clause, if present. Places a constraint on the existential to be any class type. (Implies: Only one can exist. Mutually exclusive with class name clause.)<br class=""></li></ul></div><div class=""><br class=""></div><div class="">(In the future a follow-up proposal should add in 'struct' or 'value' as a counterpart.)</div></div></div></div></div></blockquote><div><br class=""></div><div>If we’re going to allow `struct` we should also allow `enum`. `value` would allow either of those.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class=""><ul class=""><li class="">Class name. Must be the first clause, if present. (Implies: Only one can exist. Mutually exclusive with 'class'.) Places a constraint on the existential (not really an existential anymore) to be an instance of the class, or one of its subclasses.<br class=""></li></ul></div></div></div></div></div></blockquote><div>It is still be an existential if it includes protocol requirements that the class does not fulfill. For example, you might have Any<UIView, SomeProtocol> where UIView does not conform to SomeProtocol, but various subclasses do.</div><div><br class=""></div><div>Your proposal doesn’t discuss composing Any in the way that Adrian’s did like this:</div><div><br class=""></div><div>typealias Foo = Any<SomeClass, SomeProtocol, OtherProtocol></div><div>Any<AnotherProtocol, Foo></div><div><br class=""></div><div>I like the idea of composition as it allows us to factor out constraints. If we are going to do that we should allow a class to be specified in the composition as long is it is a subclass of all class requirements of Any types it composes. For example, this should be allowed:</div><div><br class=""></div><div>typealias Bar = Any<SubclassOfSomeClass, Foo, AnotherProtocol></div><div><br class=""></div><div>This is still one class requirement for Bar, it just refines the class requirement of Foo to be SubclassOfSomeClass rather than just SomeClass.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Example: Any<UIViewController; UITableViewDataSource; UITableViewDelegate></div><div class="">"Any UIViewController or subclass which also satisfies the table view data source and delegate protocols"</div><div class=""><ul class=""><li class="">Dynamic protocol. This is entirely composed of the name of a protocol which has no associated types or Self requirement.</li></ul></div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Example: Any<CustomStringConvertible; BooleanType></div><div class="">"Any type which conforms to both the CustomStringConvertible and BooleanType protocols"</div><div class=""><br class=""></div><div class="">I'm going to use 'static protocol' to refer to a protocol with associated types or self requirements. Feel free to propose a more sound name.</div><div class=""><br class=""></div><div class=""><ul class=""><li class="">Self-contained static protocol, simple. This is composed of the name of a static protocol, optionally followed by a 'where' clause in which the associated types can be constrained (with any of the three basic conformance types: subclassing, protocol conformance, or type equality). Associated types are referred to with a leading dot.<br class=""></li></ul></div></div></div></div></div></blockquote><div>Please do not introduce terms “dynamic protocol” and “static protocol”. We want to support existentials of protocols that have self or associated type requirements. The dynamic vs static distinction is a limitation of the current implementation of Swift and doesn’t make sense for the long term vision.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Example: Any<Collection where .Generator.Element : NSObject, .Generator.Element : SomeProtocol></div><div class="">"Any type that is a Collection, whose elements are NSObjects or their subclasses conforming to SomeProtocol.”</div></div></div></div></div></blockquote><div><br class=""></div><div>Swift does not allow disjunction of requirements. Only conjunctions are supported. That means the correct reading is:</div><div><br class=""></div><div>"Any type that is a Collection, whose elements are NSObjects <b class="">and</b> their subclasses conforming to SomeProtocol.”</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class=""><ul class=""><li class="">Bound static protocol. This is the same as a self-contained static protocol, but with a leading "<name> as " which binds the protocol to a generic typealias. The name can be then be used in subsequent clauses to build constraints.<br class=""></li></ul></div><div class=""><br class=""></div><div class="">Example: Any<T as Collection; IntegerLiteralConvertible where .IntegerLiteralType == T.Element>.</div><div class="">"Any type that is a Collection, and also can be built from an integer literal, in which the collection elements are the same type as the type of the integer used for the integer literal conformance.”</div></div></div></div></div></blockquote><div><br class=""></div><div>I’m not sure about this, but if we’re going to do it it should be the other way around: `Collection as T` with the alias <i class="">after</i> the name of the protocol. </div><div><br class=""></div><div>You are also using “dot shorthand” here to refer to an associated type of IntegerLiteralConvertible. I think “dot shorthand” should be limited to cases where there is only one protocol that is getting constrained. In other cases, we need to be clear about which protocol we are referring to.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">There will be rules to prevent recursive nesting. For example, if generic typealiases are allowed, they cannot refer to each other in a circular manner (like how structs can't contain themeselves, and you can't create a cyclic graph of enums containing themselves).</div><div class=""><br class=""></div><div class="">How an existential can be used depends on what guarantees are provided by the clauses. For example, 'Any<Equatable>' can't be used for much; if there were any methods on Equatable that did not use the associated types at all you'd be able to call them, but that's about it. However, 'Any<Equatable where .Self == String>' would allow for == to be called on instances. (This is a stupid example, since Any<Equatable where .Self == String> is equivalent to 'String', but there are almost certainly useful examples one could come up with.)</div></div><div class=""><br class=""></div><div class="">In order of increasing 'power':</div><div class=""><ul class=""><li class="">Don't constrain any associated types. You can pass around Any<Equatable>s, but that's about it.</li><li class="">Constrain associated types to conform to protocols.</li><li class="">Fully constrain associated types.</li></ul></div></div></div>
</div></blockquote></div><div class="">I think we need to spell out pretty clearly what members we expect to be available or not available. This section probably needs the most design and elaboration. </div><div class=""><br class=""></div><div class="">For example, we probably can’t access a member who uses an associated type as an input unless it is constrained to a specific type. On the other hand output types probably don’t need to limit access to a member. However, if the output type is Self or an associated type the visible signature would have an output type which has the relevant constraints of the existential applied, but no more. In some cases this means the output type would simply be Any.</div><div class=""><br class=""></div><div class="">Where this really gets tricky is for compound types like functions, generic types, etc. Working out the details in these cases is pretty complex. I will defer to Doug on whether it is best to just defer those cases to the future, leave them up to the implementer, or try to work out all of the relevant details in the proposal (in which case we probably need a type system expert to help!).</div><div class=""><br class=""></div><div class="">One area you didn’t touch on is “opening” the existential? Is that out of scope for this proposal? That would be fine with me as this proposal is already taking on a lot. But if so, you should mention something about future directions as it is pretty closely related to this proposal.</div><div class=""><br class=""></div><div class="">Another area you didn’t touch on is whether Any constructs (and typealiases referring to them) should be usable as generic constraints. I would expect this to be possible but I think we need to spell it out.</div><div class=""><br class=""></div><div class="">-Matthew</div></body></html>