> On May 27, 2016, at 8:14 AM, Thorsten Seitz via swift-evolution > <[email protected]> wrote: > > >> Am 27.05.2016 um 10:45 schrieb Austin Zheng <[email protected] >> <mailto:[email protected]>>: >> >> As far as I understand it (and the core team as well, judging from their >> posts), an existential is just a type defined by an interface of some sort >> ("there exists a type that is capable of X, Y, and Z"), and you can put any >> value of a type that meets that interface in the existential. > > Yeah, that is an unfortunate issue with the use of "existential“ in Swift as > opposed to its use elsewhere (e.g. Wikipedia, Haskell).
Interesting. I have had this understanding of existential since long before Swift was public. > > >> The associated types/self types requirements are non-essential add-ons. > > But these are what makes the new construct necessary in the first place. > Because currently protocols with such requirements can only be used as > constraints in generics and not as types. > To make them usable elsewhere is a feature of writing `any<P>` which is an > existential type like defined outside of Swift in Wikipedia or Haskell, i.e. > a type with an unbound type parameter. > (An alternative to having to use `any<>` would to make this interpretation as > existential implicit and allow adding constraints by a following `where`). > > That’s why I would like to either > - restrict `any<…>` to only protocols with unbound associated types or self > type requirements > - allow `any<T>` for all protocols and classes, where this just means > `any<T>` == `T` iff T has no unbound associated types or self requirements > - do away with `any<…>` altogether and automatically interpret `P` as an > existential when used as a type and use `P & Q` instead of `any<P, Q>` > > -Thorsten > > > >> >> I am about to fall asleep, though, so I'd be happy to reread the article >> tomorrow and if I'm wrong, make the change. >> >> Austin >> >>> On May 27, 2016, at 1:42 AM, Thorsten Seitz <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> Am 27.05.2016 um 10:30 schrieb Austin Zheng <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> Thank you for all your great feedback! >>>> >>>> Let me try rephrasing what I said, because it wasn't very clear. Apologies. >>>> >>>> NSView is not an existential, like you said. >>>> >>>> Any<...> syntax is, as far as we've seen, always used for existential >>>> types. >>>> >>>> "Any<NSView>" *looks* like an existential because it has the "Any<...>" >>>> syntax, but if it's a synonym for just "NSView" then it actually isn't an >>>> existential. >>>> >>>> So "Any<NSView>" isn't an existential, but it looks like one. This is >>>> something I think would be confusing to a lot of people, and also >>>> redundant: there is no reason as far as I know to ever write >>>> Any<SomeClass> when you could just write SomeClass, so by banning the >>>> confusing form we don't lose any expressive power. >>> >>> Ah, ok! So `Any<NSView>` is just the same as `NSView`. That’s my >>> understanding as well :-) >>> >>> But this does not apply only to classes: `Any<CustomStringConvertible>` is >>> just the same as `CustomStringConvertible`, too, because >>> `CustomStringConvertible` does not have associated types or self type >>> requirements (it is *not* an existential in Wikipedia’s sense). >>> >>> Banning `Any<Foo>` where `Foo` does not have associated types or self type >>> requirements would be the right thing to do, I think, regardless whether >>> `Foo` is a class or a protocol. This would make it clear that `Any<Foo>` is >>> a *real* existential. >>> >>> -Thorsten >>> >>> >>>> >>>> Hope that helps, >>>> Austin >>>> >>>>> On May 27, 2016, at 1:24 AM, Thorsten Seitz <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>>> >>>>>> Am 26.05.2016 um 22:44 schrieb Austin Zheng via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>>: >>>>>> >>>>>> (inline) >>>>>> >>>>>> On Thu, May 26, 2016 at 12:22 PM, David Hart <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>> >>> >> > > _______________________________________________ > 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
