[swift-evolution] Enhanced existential types proposal discussion

Thorsten Seitz tseitz42 at icloud.com
Fri May 27 03:24:51 CDT 2016


> Am 26.05.2016 um 22:44 schrieb Austin Zheng via swift-evolution <swift-evolution at swift.org>:
> 
> (inline)
> 
> On Thu, May 26, 2016 at 12:22 PM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
> Hi Austin,
> 
> I never had te occasion to say thanks for the work you have put in this proposal, so thanks! I’m really looking forward to be able to have some form of it accepted and implemented in Swift.
> 
> Thank you! I just hope a proposal like this one ends up being good enough that it means less work for the core team, not more...
>  
> 
> Here are a few comments:
> 
> 1) Why would Any<> and Any<NSView> be illegal? What error messages would they generate? Why not make them simply synonymous to Any, and NSView, the same way protocol<> currently behaves?
> 
> "Any<>" being illegal is a syntactic battle that is being fought over in a different thread; I'm not personally invested one way or another. (We might not even adopt "Any" syntax specifically; Joe Groff has ideas for a different syntax that doesn't use the brackets.)
> 
> "Any<NSView>" is an existential, and "NSView" isn't. Existentials' metatypes are different from the metatypes of concrete types, and the ways they can be used with generics is different as well. My opinion is that Any<...> signifies an existential, and allowing the use of "Any<SomeClass>" as a concrete type would just confuse people even more.


This is something where I still have a problem understanding what an existential is in the Swift sense. In the "normal“ sense (as defined in Wikipedia or Haskell) NSView cannot be an existential because it has no unbound associated types. It cannot be just made an existential either. How would that work?

So, what is the meaning of `Any<NSView>` being an existential? How is that type different from the type `NSView`?

-Thorsten

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


More information about the swift-evolution mailing list