[swift-evolution] [Proposal] Separate protocols and interfaces

[Dave Abrahams]

> On Jan 3, 2016, at 10:25 AM, Антон Жилин via swift-evolution <swift-evolution at swift.org> wrote:
> 
> The problem with syntax of "existential protocol" and "protocol" is that the first should actually be default, and easier to write.
> 
> We should prefer static to dynamic.

These two statements seem to be in conflict: existentials create dynamic polymorphism, while generics create static polymorphism.

> It is as if "structs" had to be declared as "static class", or "let" variables as "const var". Shorter keywords should be used for enforcing good practices.
> Additionally, 95% of standard library protocols are actually "existential protocols", or "protocols" in my notation.
> 
> Next, I don't know any language which has "existential" keyword. Moreover, "existential types" in Haskell mean means (roughly) "type that can hold value of any instance of class with type erasure", and that is exactly what an interface is in Swift. So, I think that if we will add "existential" keyword, we would add it the other way: for dynamically dispatched types.
> 
> Some other suggestions (imagine a table):
> 
> statically dispatched - dynamically dispatched
> protocol - interface
> protocol - dynamic protocol
> protocol - existential protocol
> static protocol - dynamic protocol
> trait - protocol
> trait - interface
> 
> I also personally like the "trait - protocol" naming. Traits are used to be statically dispatched things in other languages, and protocols are dynamically dispatched things from Objective-C. Actually, I'm satisfied with any pair unless dynamic protocols get shorter names.
> 
> P.S. I'll correct that Self issue, thanks!
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160103/fef475ef/attachment.html>