I had decided to watch from the sideline, but a couple things push me to say something
> On Jun 13, 2016, at 4:04 AM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > on Fri Jun 10 2016, Thorsten Seitz <tseitz42-AT-icloud.com > <http://tseitz42-at-icloud.com/>> wrote: > >>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution >>> <[email protected]>: >>> >>> >>>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution >>>> <[email protected]>: >>>> >> >>>> >>>> on Wed Jun 08 2016, Jordan Rose <[email protected]> wrote: >>>> >>>>>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> on Wed Jun 08 2016, Thorsten Seitz >>>>> >>>>>> <[email protected] >>>>>> <mailto:[email protected]>> >>>>>> wrote: >>>>>> >>>>>>> Ah, thanks, I forgot! I still consider this a bug, though (will have >>>>>>> to read up again what the reasons are for that behavior). >>>>>> >>>>>> Yes, but in the case of the issue we're discussing, the choices are: >>>>>> >>>>>> 1. Omit from the existential's API any protocol requirements that depend >>>>>> on Self or associated types, in which case it *can't* conform to >>>>>> itself because it doesn't fulfill the requirements. >>>>>> >>>>>> 2. Erase type relationships and trap at runtime when they don't line up. >>>>>> >>>>>> Matthew has been arguing against #2, but you can't “fix the bug” without >>>>>> it. >>>>> >>>>> #1 has been my preference for a while as well, at least as a starting >>>>> point. >>>> >>>> I should point out that with the resyntaxing of existentials to >>>> Any<Protocols...>, the idea that Collection's existential doesn't >>>> conform to Collection becomes far less absurd than it was, so maybe this >>>> is not so bad. >>> >>> I think the problem is more that Any<Collection> does not conform to >>> a specific value for a type parameter T: Collection >>> >>> What I mean by this is that `Collection` denotes a type family, a >>> generic parameter `T: Collection` denotes a specific (though >>> unknown) member of that type family and `Any<Collection>` denotes >>> the type family again, so there is really no point in writing >>> Any<Collection> IMO. >>> The type family cannot conform to T because T is just one fixed member of >>> it. >>> It conforms to itself, though, as I can write >>> let c1: Any<Collection> = … >>> let c2: Any<Collection> = c1 >>> >>> That’s why I think that we could just drop Any<Collection> and simply write >>> Collection. >> >> Let me expand that a bit: >> >> Actually all this talk about existentials vs. generics or protocols >> vs. classes has had me confused somewhat and I think there are still >> some misconceptions present on this list sometimes, so I’ll try to >> clear them up: > > There are several objectively incorrect statements here, and several > others with which I disagree. I was hoping someone else would write > this for me, but since the post has such a tone of authority I feel I > must respond. > >> (1) misconception: protocols with associated types are somehow very >> different from generics >> >> I don’t think they are and I will explain why. The only difference is >> the way the type parameters are bound: generics use explicit parameter >> lists whereas protocols use inheritance. That has some advantages >> (think long parameter lists of generics) and some disadvantages. >> These ways are dual in a notation sense: generic types have to have >> all parameters bound whereas protocols cannot bind any of them. >> The „existential“ notation `Any<>` being discussed on this list is >> nothing more than adding the ability to protocols to bind the >> parameters to be used just like Java’s wildcards are adding the >> opposite feature to generics, namely not having to bind all >> parameters. > > Protocols and generics fulfill completely different roles in Swift, and > so, **especially in a language design context like the one we're in > here**, must be thought of differently. The temptation is great to mention your own words from 2+ years ago regarding the choice of the name Protocol instead of Interface, and the ‘hope’ (your word) that the differentiation would wind-up being big enough to justify the new name. Wanting to view them in a different light is one thing, succeeding in establishing a gap wide enough that people with superficial or intimate knowledge of both would come to the unavoidable conclusion that they are fundamentally different, is an entirely different exercise. At this point I think it is fair to say that the differences are notable but, perhaps out of lack of familiarity with the details, not quite strong enough to make all developers reach the conclusion you’d like them to reach. > The former are an abstraction > mechanism for APIs, and the latter a mechanism for generalizing > implementations. The only place you could argue that they intersect is > in generic non-final classes, because a class fills the dual role of > abstraction and implementation mechanism (and some might say that's a > weakness). But even accounting for generic classes, protocols with > associated types are very different from generics. Two utterly > different types (an enum and a struct, for example) can conform to any > given protocol P, but generic types always share a common basis > implementation. There is no way to produce distinct instances of a > generic type with all its type parameters bound, but for any protocol P > I can make infinitely many instances of P with P.AssociatedType == Int. somehow I think both your arguments contain some truth. You are pointing out the differentiating fact that a Protocol is abstracting across multiple concrete types, while he is showing that the mechanism in which associated types in a Protocol is reminiscent of the way a type T operates on a generic type. The two are not mutually exclusive. In all cases, "A is to B what 1 is to 2” has never meant that 1 and A are the same, it simply means that the relationship inside each pair operates in a similar fashion to the relationship within the other pair; which again is very different from saying that the relationships are the same. In this context, I think that there is a strong case for wanting to further bridge the gap, as was even pointed out by Doug in his Generics Manifesto. Not to mention that Java and a few others are there to demonstrate how far the similarities can be pushed. > Back to the my original point: while protocols and generic types have > some similarities, the idea that they are fundamentally the same thing > (I know you didn't say *exactly* that, but I think it will be read that > way) would be wrong and a very unproductive way to approach language > evolution. Yes, similarities are just that, and I am absolutely with you to claim that they are NOT THE SAME, and it is unfortunate that analogies get so often confused with alike-ness. Although it is undeniably helpful for people to learn new concepts via their alike-ness to other concepts, it can also create the wrong mental picture. Unfortunately I think that 10s of thousands of years of evolution are conspiring to make our brains likely to jump from analogous to alike quite readily, wiping out critical differences in the process. >> Essentially `Any<Collection>` in Swift is just the same as >> `Collection<?>` in Java (assuming for comparability’s sake that >> Swift’s Collection had no additional associated types; otherwise I >> would just have to introduce a Collection<Element, Index> in Java). > > I don't see how you can use an example that requires *assuming away* > assoociated types to justify an argument that protocols *with associated > types* are the same as generics. You might have to write a lot of educational material on the language to cast the “the relationship between protocols and their associated types is analogous to the relationship of a generic type and its parameters” in stone, and dispel the “protocols are the same as generics” views. I do hope this is a topic you will dwell-on in your presentation at WWDC this week, openly presenting the similarities to better point out the critical differences !!!! :) >> Likewise `Any<Collection where .Element: Number>` is just the same as >> `Collection<? extends Number>` in Java. >> >> And just like Collection<?> does not conform to a type parameter `T >> extends Collection<?>` because Collection<?> is the type `forall >> E. Collection<E>` whereas `T extends Collection<?>` is the type >> `T. Collection<T>` for a given T. >> >> In essence protocols with associated types are like generics with >> wildcards. > > It is true that generics with wildcards in Java *are* (not just “like”) > existential types but I don't agree with the statement above. Because > Java tries to create an “everything is a class” world,generic classes > with bound type parameters end up playing the role of existential type. > But protocols in Swift are not, fundamentally, just existential types, > and the resyntaxing of ProtocolName to Any<ProtocolName> for use in type for as much as I would prefer the "var p : ProtocolName” and its extension to “var t : UITableView[UITableViewDataSource & UITableViewDelegate], I do understand wanting to surrender to Any<UITableView & UITableViewDelegate> to carve the difference with the Generics in the hardest marble. But I do think that over time people will forget the meaning and just get into the habit of writing code that will just work. > context is a huge leap forward in making that distinction clear... when > that's done (unless we leave Array<ProtocolName> around as a synonym for > Array<Any<ProtocolName>>—I really hope we won't!) protocols indeed > *won't* be types at all, existential or otherwise. > >> Coming back to the questions whether (a) allowing existentials to be >> used as types is useful > > That's the only use existentials have. They *are* types. Of course > they're useful, and I don't think anyone was arguing otherwise. :) I sure hope not… > >> and (b) whether sacrificing type safety would somehow be necessary for >> that, I think we can safely answer (a) yes, it *is* useful to be able >> to use existentials like Any<Collection> as types, because wildcards >> are quite often needed and very useful in Java (they haven’t been >> added without a reason) (b) no, sacrificing type safety does not make >> sense, as the experience with Java’s wildcards shows that this is not >> needed. > > I would call this “interesting information,” but hardly conclusive. > Java's generics are almost exactly the same thing as Objective-C > lightweight generics, which are less capable and less expressive in > many ways than Swift's generics. This is the part that had me jump in my seat… With all due respect, I find this a very reductionist view. As things stand, Java generics covers both classes and interfaces equally, which the swift generics+protocol&assocType is far from doing. It has to be the case or this thread would not exist and Austin and myself would not have bothered to write long proposals to attempt to fill the gap. Furthermore, Java & JVM are currently undergoing an effort to any-fy the generics system that will result in a number of new doors opening: Collection<any> that includes int, reification of generic parameters inside the .class, … when coupled with the other ongoing effort to add value types, then the difference with swift would be in the direction of swift having some serious catchup to do. I do hope that the current status-quo between Generics and Protocols will not remain what it is and that some form of the extended existential proposals (ok… I can’t resists: https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051) will have made it into swift by then. I place existentials/dynamic polymorphism high on my TODO because looking at the evolution of Java in the last 3 years, the greatest leaps have come from this part of the language. But I do understand that when looking at where Apple developers come from with Objc, it may seem that that this form of abstraction may seem far away on their priority list. However IMHO designing swift to be a simple upgrade for objc might be missing the point that today, even Typescript has a very powerful way of abstracting over generic interfaces. >> Especially if something like path dependent types is used like >> proposed and some notation to open an existential’s type is added, >> which is both something that Java does not have. >> >> (2) misconception: POP is different from OOP >> >> It is not. Protocols are just interfaces using subtyping like OOP has >> always done. They just use associated types instead of explicit type >> parameters for generics (see above). > > They are not the same thing at all (see above ;->). To add to the list > above, protocols can express fundamental relationships—like Self > requirements—that OOP simply can't handle. There's a reason Java can't > express Comparable without losing static type-safety. self requirements on interfaces would be a very nice addition to java… > Finally, in a > language with first-class value types, taking a protocol-oriented > approach to abstraction leads to *fundamentally* different designs from > what you get using OOP. Looking at the code people actually write, I’m afraid this may be a tough battle to win… >> The more important distinction of Swift is emphasizing value types and >> making mutation safely available by enforcing copy semantics for value >> types. > > We don't, in fact, enforce copy semantics for value types. That's > something I'd like to change. But regardless, value types would be a > *lot* less useful if they couldn't conform to protocols, and so they > would be a lot less used. Heck, before we got protocol extensions in > Swift 2, there was basically *no way* to share implementation among > value types. So you can't take protocols out of the picture without > making value types, and the argument for value semantics, far weaker. > >> But protocols are not really different from interfaces in Java. >> I would have preferred a unified model using just classes with real >> multiple inheritance like Eiffel has and value types just being a part >> of that similar to Eiffel’s `expanded` classes. But that ship has >> probably sailed a long time ago :-/ So be it. But at least there >> should be no reasons for POP vs OOP wars ;-) (I’d like to add that I >> liked Dave’s talks at last WWDC very much, it’s just that I don’t >> think that POP is something new or different.) > > Protocol-oriented programming is about the synergy of features and ideas > most of which not *individually* new, but that together create a new > world of possibilities. I've already discussed the synergy of protocols > and first-class value semantics. There's also the fact that in > protocols we have one construct with which to express dynamic > polymorphism (existentials) and static polymorphism (generic > constraints), both of which have important roles to play but that I > maintain are very different indeed. One result is that you can “start > with a protocol” as your abstraction mechanism and know that you're not > going to design yourself into a corner where it becomes impossibly > awkward to express what you need. Finally—and I'm certain this *is* > new—in protocol extensions we have a means to express both post-hoc > conformance and generic functions that is much more accessible to users > than in any previous language, to the point where generic programming > can become a natural part of everyday work. As a long term Erich Gama fan and Eclipse cave-diver, I do wholeheartedly agree that protocol extensions is an incredible feature!!! It would have done wonders for all the adapters I have had to write, to be able to do that in java directly. I hope you manage to make people see how powerful they are today, and make them even more powerful in the future. As you bring the topic, I had gathered some thoughts on methods dispatching in protocol extensions : https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html Looking forward to a presentation on POP/Extensions/Generics this week.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
