[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Thorsten Seitz tseitz42 at icloud.com
Sat Jun 11 07:05:07 CDT 2016 

> Am 11.06.2016 um 12:38 schrieb L. Mihalkovic <laurent.mihalkovic at gmail.com>:
> 
> 
>> On Jun 11, 2016, at 11:30 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>> 
>> 
>>> Am 11.06.2016 um 08:00 schrieb L. Mihalkovic <laurent.mihalkovic at gmail.com>:
>>> 
>>> 
>>> 
>>> 
>>> Regards
>>> (From mobile)
>>>> On Jun 10, 2016, at 9:35 PM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution <swift-evolution at swift.org>:
>>>>> 
>>>>> 
>>>>>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution <swift-evolution at swift.org>:
>>>>>> 
>>>>>> 
>>>>>> on Wed Jun 08 2016, Jordan Rose <swift-evolution at swift.org> wrote:
>>>>>> 
>>>>>>>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
>>>>>>>> <swift-evolution at swift.org> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> on Wed Jun 08 2016, Thorsten Seitz
>>>>>>> 
>>>>>>>> <swift-evolution at swift.org
>>>>>>>> <mailto:swift-evolution at swift.org>>
>>>>>>>> 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.
> Yes.. I just don't like magic. I think that all types should be expressable with a syntax and that you can then decide to alias one parsing case with a specific name. Not the other way around.

Well, I think that would be backwards, because we have a nominal type system. That means that the syntax for a type is just its name. 
`&` is a type operator which creates a new type from its operands.
`where` clauses add constraints to types.
But it all starts with a type's name.

The only magic would be that all type definitions (`protocol` etc.) which do not give a supertype they conform to, will implicitly conform to `Any`, i.e.

protocol Foo { … }

means

protocol Foo : Any { … }

That’s less magic than creating a special syntax just to express the top type.


> 
>> 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).
> The _[] case is just a degenerate case of the syntax, showing that it is expressible inside, as opposoed to have to define a contextual keyword (read the SourceKit code). And then it is aliasable. Part of the problems in swift today to me is that some things are no doable in swift, so the compiler must contain that semantic. This here is just one example, but there are others. These are notions that the standard library has to defer to the compiler. Some of them have been tabled for 4.0 it seems. My point here was that it is not fate, and choosing the syntax carefully for existentials (whichever it is, i don't really care inthe end) would prevent having to add a magic keyword for to top type to the compiler and to SourceKit again (they are trying to remove them).

`Any` would *not* be a keyword. It is just a type name like `Collection` or `Int`. Like I said, the only magic would be in adding `: Any` to type definitions without a conforming clause.

> 
> As for the current Any<...> proposal for generalizing existentials it is IMHO cluncky and magic. There is nothing stopping us mechanically from entering Any<UITableView, UIButton>. To me that is the holemark of bad design. In what I tested you just can't do it and the reason is clear. Of course when I

`Any<UITableView, UIButton>` is just an intersection type and would be written UITableView & UIButton. And, yes, that would be ok, because it would be just the empty set, i.e. the bottom type (which has no members). There is no magic involved, it is just the normal result of an intersection: each type is a set containing all instances of this type (instances conforming to it). Intersecting two sets might result in an empty set. The type denoting the empty set is the bottom type which is the subtype of all types and might be called `Nothing` or `Never` or `Bottom`.
Ceylon makes very nice use of type intersections and type unions and the beautiful thing is that these type operations really just work like you would expect if you think of types as sets (which is the standard definition for a type AFAIK). No surprises and no magic there!

So it is *not* a sign of bad design, quite to the contrary! What did you test it with? Probably not Ceylon, because otherwise you would have seen that it just works.


> say you can't I do not mean that your keyboard will zap u if you try. But the way to verify correctness is different... and in a world where xcode would be a good ide, then code completion would even show you why and actually truly assist (because the grammar i tested makes really makes it possible). I know that xcode is only as good as SourceKit lets it be.
> 
>>> 
>>>> 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?
> 
> Yes. After 10. Than is their only date hint.
> 
>> 
>> 
>>> 
>>>> 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 with 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 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 typesafe 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?
> 
> Yes, and no. It has differently dispatched code that can be found to fill in the gap of the conformance req, yes. But Joe Grof (?) said that there are no reasons why these could not be added. Having true defaults could be one way to deal with optional comformance…

The dispatch issue only arises for extensions introducing a method that is not declared in a protocol. That is something you *cannot* do in Java. Java’s default methods are implementations for methods declared in interfaces. Swift’s extension methods providing defaults for methods declared in a protocol are dynamically dispatched and should work like Java’s default methods.
(One caveat exists with subclasses where the superclasses didn’t implement the method because I then am not allowed to `override` the default method but that is a bug IMO).

-Thorsten



> 
> protocol MyProto {
> func mustImplement()
> default canImplement() { } 
> }
> 
> Related data there:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html
> 
>> 
>> 
>>> 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.
> 
> I think I care more about existentials, but only because of the kind of java i wrote for a living. I just looked at a bunch of opensource swift libs (particularly for server side swift)... some of it is a real engineering disaster: 20+ folders, each with 2 source files... or 3 folders "extensions" "utils" "classes". Swift is currently not equiped for people to write big things with... I wish the team would address it sooner than later (look at their own c++ code to see the difference). IMHO import conflicts are more often the symptom of bad code than a real issue.

Alas, most languages suffer from poor module systems. A good module system should not only allow resolving conflicts between modules and making it possible to structure code well, but solve the issue around versioned modules so that is is possibly to safely use different versions of the same module in the same application.

-Thorsten


> 
> Cheers
>> 
>> -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
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>

More information about the swift-evolution mailing list