> Am 11.06.2016 um 08:00 schrieb L. Mihalkovic <[email protected]>: > > > > > Regards > (From mobile) >> On Jun 10, 2016, at 9:35 PM, Thorsten Seitz via swift-evolution >> <[email protected]> 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: >> >> (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. > > btw, i tried to to see if Any<> could have a simpler alternative > https://gist.github.com/lmihalkovic/8aa66542f5cc4592e967bade260477ef
As you know I like using `&` as type intersection operator. But you write "The syntax leave a void when it comes to expressing the so called Top type:“ Why? Just give the top type a name, e.g. `Any` and you are done. Why should the top type have special *syntax*? It is just the type all other types conform to. No need to do something special here and therefore no need to invent an alternative syntax like `Any<>` or the alternative from your gist which is rather confusing IMO (and I don’t like the special case given to classes in the syntax). > >> 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). >> >> Likewise `Any<Collection where .Element: Number>` is just the same as >> `Collection<? extends Number>` in Java. > Java supports co/contra variant params Java has no declaration-site variance like Ceylon or Scala have (see e.g. http://ceylon-lang.org/blog/2014/07/14/wildcards#why_i_distrust_wildcards_and_why_we_need_them_anyway). Java’s wildcards are a way to express use-site variance. The proposed `Any<>` does just the same. > >> 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. > > This picture is accurate today, but there are going to be more serious > differences after 10 no date is currently geven for when it will come) You mean Java 10? > >> In essence protocols with associated types are like generics with wildcards. > > Yes, java has kept everything within its generics system rather than split > parts out. Something people may not immediately think about iwith respect to > the 2 generic systems is that when u call a func<T>capture(T t){} in java > with a wildcard you are doing a compile time capture only (to avoid the > dreaded unsafe casts), whereas it is really nice to do the same in swift and > subsequently be able to access T.Type and see that it is not Any. The closest > u ever get to that type at runtime in java is via generics introspection, but > u still can't do everything ( like no new T() ). But today the bridging > between existential types and generics is definitely a work in progress. > >> Coming back to the questions whether (a) allowing existentials to be used as >> types is useful 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) > > IMO they made java 8 (referring to streams). And even though the syntax for > co/contra variance is pretty heavy, it is the foundation for all modern java > code. The any-fication of the generics is going to open new doors as some of > it will translate into A partial reification in the jvm. It seems the > decision for now the decision is to not use the extra info in java to retain > binary compatibility with all the erased code out there, this is something > scala might use in areas where it won't mind loosing java compatibility. > >> (b) no, sacrificing type safety does not make sense, as the experience with >> Java’s wildcards shows that this is not needed. 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. > > I hope sypesafe opening inside the " if let " syntax gets added. I know that > chris is against sugaring, but I played if an implementation of > > ... x is String? > If let! x {} > That runs as > if let x = x {} > > something equally short could be done here. > >> >> (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). The more important distinction of Swift is emphasizing >> value types and making mutation safely available by enforcing copy semantics >> for value types. > > Values are coming to the jvm, which will narrow this gap (like their view > identity for value vs ref and the whole deep ==) . I also really like the cow > approach of the swift runtime. > >> But protocols are not really different from interfaces in Java. > > There is one big difference: default methods, but it seems swift will add > that soon. Swift already has default extension methods, doesn’t it? > I also really like how extensions and conformance mix together in swift to > bake retro-modelling in and the adapter pattern (spent enough years deep > diving inside eclipse to appreciate it). > >> 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 :-/ I like extensions very much (having used Smalltalk for a long time). I like enums for the pattern matching and structs as value types. But having to split protocols off instead of using abstract classes makes things more complicated IMO. > -1 i am old school c/c++... i really like protocol, struct, class, > extensions, enums. It is a really nice mix that gives objc people room to > grow, but I do miss how they are an integral part of generics (i protocols as > a replacement and look forward to when they interact better) and > namespaces+scoped-imports (c#)... Looking forward to where things go next Yeah, namespacing/submodules/conflict resolution (when doing imports but also when conforming to multiple protocols which has just the same problems) are still missing. But I’m optimistic :-) Let’s complete generics first, then tackle existentials/type intersections. -THorsten > >> 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.) > > I used to thin that way. But today I think that although in broad brush > strokes the similarities and bigger than the differences, there is room for > making a bigger difference in the how. > >> >> >> -Thorsten >> >> >> >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
