<div dir="ltr">Going through my code comments & notes now to see where the ideas here could've helped avoid some nasty hacks. I'll try to keep this mostly to (missing) features I've found problematic but haven't seen mentioned here and quick votes with comments that I think won't be responded to, and then fork off deeper discussions into their own threads as suggested.<div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote"><div><b>Missing feature: How do protocols interact with the package system?</b></div><div><br></div><div>Javascript had an unfortunate situation a couple years ago where there were about a dozen competing Promise implementations. The leading libraries all got together and came up with the Promises/A+ spec. Because Javascript is dynamically typed, the spec mandates that anything with a then() method is "Promise-like", and can be chained into existing promises. As a result, you can take a library that uses Bluebird promises, pass them to a library that uses the es6-promise Polyfill, and then use the native implementation of Promise.all and everything will just work.</div><div><br></div><div>Swift is not dynamically typed - to indicate a common set of functionality, you need to define a protocol. What happens when multiple frameworks define a protocol that other frameworks wish to use? I know of at least 3 different mutually-incompatible Promise implementations for Swift, but assuming they managed to reconcile their differences and come up with a common API - how would a library wanting to use this spec ensure that it's compatible with other libraries using the spec? If I include promises.swift in my project which defines "public protocol Promise { ... }", will the compiler know that it's the same protocol as the identical promises.swift in AlamoFire or RethinkDB? If not - how could it be packaged up on its own so that everyone can be good citizens and interoperate with each other? Will app developers using these libraries need to install a long chain of dependencies, or can they just get their leaf dependencies and trust that everything will work together? What happens if there are versioning inconsistencies behind the protocols that library dependencies use?</div><div><br></div><div><b>Missing feature: "protocol can only be used as a generic constraint"</b></div><div><br></div><div>This error message pops up whenever you try to use a protocol that has associated types or Self (in a non-return position) as a type. Instead of being able to write "func doSomething(obj: MyProtocol)", you now have to write "func doSomething<T: MyProtocol>(obj: T)", and you can forget about being able to store objects of these protocols in data structures. As I understand it, this is because of conceptional confusion on the part of the dev: when a protocol has associated types, it's no longer a <i>type</i>, but a <i>type family</i>, and so it doesn't make sense to use it as you would a type. The compiler would have to enforce invariants that it doesn't have the information to enforce.</div><div><br></div><div>That said, is there anyway to reduce the impact of this error message (which, based on several Google searches and a bunch of encounters with it myself, seems to happen quite frequently)?</div><div><br></div><div>In my experience, this error seems to pop up most often in two common circumstances:</div><div><br></div><div>- Adopting Equatable or Hashable in a protocol</div><div><br></div><div>Solved by existentials - the usage of the protocol becomes an existential. In particular, "opening existentials" is usually what you'd want to do for ==; I'm not really sure I like the syntax proposed here but this thread isn't for bikeshedding. :-)</div><div><br></div><div>- Making a protocol inherit from a collection</div><div><br></div><div>Examples of this might include having a Message object behave like [String:AnyObject], having an Amazon S3 interface behave like [String:NSData], or having a File behave like [String] (like in Python). Assume that concrete adopting classes cannot change the associated types.</div><div><br></div><div>The interesting thing about this case is that all of the associated types are nailed down, and their usage can be limited to default method implementations that don't vary between the concrete types adopting the protocol. So in such a File, the Generator implementation would always delegate to self.readLine(), the SubSequence type is always [String], and the only time these types are referenced is on default methods on File which themselves delegate to the protocol methods witnessed by adopting types.</div><div><br></div><div>IIUC, the compiler should have enough information available to generate all code required by a File parameter, right? It knows the associated types of the collection, and it knows the methods that generate them.</div><div><br></div><div>Could this special case be fixed?</div>
<div><br></div><div><b>Missing feature: How does toll-free bridging with Foundation interact with protocol extensions?</b></div><div><br></div><div>Last time I checked, an Array is-a NSArray and vice versa; they satisfy is/as checks, they can be used interchangeably, and methods on one are available on the other. Except for with protocol extensions. When you extend Array to conform to a protocol, you don't automatically get NSArray as well. You have to explicitly define a conformance for NSArray as well, which often has exactly the same code.</div><div><br></div><div>This is more a source of head-scratching & annoyance than a fundamental limitation, since you can always duplicate the code and factor the logic out to a common helper. But it's one that's likely to be propagated through the library ecosystem, as library authors who grow up on Swift forget about NSArray/NSDictionary/etc. and then their code just doesn't work for people switching over an Objective-C app.</div><div><br></div><div><div class="gmail_quote">On Wed, Mar 2, 2016 at 5:22 PM, Douglas Gregor via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><i style="font-size:14px">*Conditional conformances<br></i></div><div><br></div></div></blockquote><div><br></div><div>Big +1. This is necessary for any sort of extensible tree structure. Think about JSON serialization, for example: an array or dictionary is JSON serializable only if all of its elements are JSON serializable, and the algorithm used to serialize it depends on a call to serialize its members. It comes up in many UI areas as well: a UI component might be Persistable iff all of its subviews are Persistable.</div><div><br></div><div>The lack of this prevents app code from being able to easily extend functionality provided in a library, eg. I may be able to easily come up with a JSON serialization of a CLLocation or CNContact, but SwiftyJSON will be unable to serialize an array of these objects using my mechanism.</div></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><span style="font-size:14px"><i>Concrete same-type requirements</i><br></span></div><div><br></div></div></blockquote><div> </div><div>Big +1 on this as well. It seems like it's pretty uncontroversial, but this is widely applicable across a number of domains. Basically any time you need to operate on a generic collection with operations that only make sense on a particular element type.</div><div><br></div><div>This would also increase the usefulness of "Generic typealiases" - the two proposals together let you define new generic types just by adding extensions to existing generic types. Good way to prototype, and then if the extension gets too complicated, you can always take what you've learned and make a real type.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div><i style="font-size:14px">Parameterized extensions</i></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br></div></blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span style="font-size:14px"><i>*Arbitrary requirements in protocols</i></span></div></div></blockquote><div><br></div><div>These two both seem nifty, but I'm having trouble thinking of a concrete use-case where they'd be critical. The "arbitrary requirements in protocols" in particular seems to be going down the path of "let's embed a constraint solver in the Swift compiler", which seems like it'd lead to some fun webpages a la <a href="http://okmij.org/ftp/Computation/type-arithmetics.html" target="_blank">type arithmetics</a>, but not something you'd want to see in your coworker's code.</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div><div><div><span style="font-size:14px"><i>Default generic arguments </i></span></div></div><div><br></div></div></blockquote><div><br></div><div> Is it within Swift's scope to support compile-time polymorphism for high performance computing? This is a common technique in C++: you want a generic algorithm that must be specialized in one or two places, but can't afford the run-time overhead of dynamic dispatch. So you create a template parameter with a functor type. STL allocators are a good example.</div><div><br></div><div>I don't personally do much HPC and dunno if it fits within Apple's vision for Swift, but there are few other options if you do, and default generic args make this tactic much more convenient. Also fits well with "Named generic parameters" and "Generic value parameters". Might combine awkwardly with "Variadic generics" and "Moving the where clause out of the angle brackets" (would the default be specified inside the angle brackets or outside?).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><span style="font-size:14px"><i>*Allowing subclasses to override requirements satisfied by defaults</i></span></div><div><span style="font-size:14px"><i><br></i></span></div><div><br></div></div></blockquote><div><br></div><div>Necessary for "Dynamic dispatch of protocol extensions" and "default implementations in protocols" to make sense, right? +1 to all three, it seems like this is a cluster of related improvements that would make things more uniform & understandable.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div><span style="font-size:14px"><i>Variadic generics</i></span></div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="Menlo"><br></font></div></blockquote></div></blockquote><div><br></div><div>I'll fork off a thread on this...I've got some thoughts specifically related to use with function types.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><div><span style="font-size:14px"><i>*Default implementations in protocols</i></span></div></div><div><br></div><div><div><br></div></div></div></blockquote><div><br></div><div>+1. It's cosmetic only, but the "use an extension to provide default members of a protocol" idiom can be very confusing to newcomers.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span style="font-size:14px"><i>*Renaming “protocol<…>” to “Any<…>”.</i></span></div><div><br></div></div></blockquote><div><br></div><div>+1. protocol<> always struck me as weird. Any<...> is pretty similar to equivalent concepts in other languages, like union types in Dylan.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><i style="font-size:14px">*Moving the where clause outside of the angle brackets</i><br></div></div></blockquote><div><br></div><div>-1. Haskell does it this way (and pretty much has to because of MPTCs with fundeps). I found it was one of the hard parts of learning Haskell - I'm used to thinking of a type as a unit. Adding generics to that unit isn't too hard to wrap my head around. Adding constraints to those generics isn't that hard, although at that point the type signatures are getting really long. (The proposals for "Generic typealiases" and "Typealiases in protocols and protocol extensions" could help ameliorate this. Is it possible to typealias constraints as well?) Wondering what the hell this "where" clause is and how it relates to these generic things and why it's at the end of the function signature can get pretty confusing.</div><div><br></div><div>Also, how does this interact with generic constraints on class/structs? Would it go after the full struct definition, or just after the class name? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><b><br></b></div><div><div><span style="font-size:14px"><i>Dynamic dispatch for members of protocol extensions</i></span></div><div><br></div><div><br></div></div></div></blockquote><div><br></div><div>Static dispatch is very confusing here. The whole point of protocols is to get ad-hoc polymorphism, so when a protocol default message is called instead of the overridden version just because of the static type signature of the variable, it's likely to result in much head-scratching.</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div><div><div><br></div></div><div><br></div><div><div><b><font size="4">Potential removals</font></b></div><div><b><br></b></div><div>The generics system doesn’t seem like a good candidate for a reduction in scope; most of its features do get used fairly pervasively in the standard library, and few feel overly anachronistic. However...</div><div><br></div><div><span style="font-size:14px"><i>Associated type inference</i></span></div></div><div><br></div></div></blockquote><div><br></div><div>The consequence of its removal is just that classes/structs that conform to IteratorProtocol will now have to say "associatedtype Element = Int"? I don't view that as a major hurdle. It's a bit of an annoyance, but if it makes the typechecker significantly simpler and allows implementation of some of the other ideas here, I think it's worth it. It would be more problematic if it required extra declarations at the call site; functions are called orders of magnitude more times than classes & structs are declared.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div><b><font size="4">Existentials</font></b><br><br>Existentials aren’t really generics per se, but the two systems are closely intertwined due to their mutable dependence on protocols.<br><br><span style="font-size:14px"><i>*Generalized existentials</i></span></div><div><br></div><div><i style="font-size:14px">Opening existentials</i></div><div><br></div><div><br></div></div></blockquote><div><br></div><div>+1 on both of these. I remember writing a <a href="https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours" target="_blank">Haskell tutorial</a> several years ago, and it was amazing how quickly you needed existentials. It's not uncommon to want a heterogenous collection of objects that all implement a single protocol; generics don't give you this.</div><div><br></div><div>There's an existing thread on this, so I'll send comments on the syntax & usage of this over that way.</div></div><br></div></div></div>