[swift-evolution] Enhanced existential types proposal discussion

L. Mihalkovic laurent.mihalkovic at gmail.com
Fri May 27 06:02:30 CDT 2016


> On May 26, 2016, at 10:56 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>>> I alway enjoy hearing your ideas.
>>>> 
>>>> This is quite interesting. It's basically a way to define an ad-hoc interface that a type doesn't need to explicitly declare it conforms to. I know Golang works similarly; if a Go type implements all the requirements of an interface it conforms automatically.
>>>> 
>>>> There are positives and negatives to allowing this sort of ad-hoc interface.
>>> 
>>> Agree.  It would definitely make the language "feel" a bit more fluid.  But it doesn't add any expressive power and could have undesirable consequences.
>>> 
>>>> This would make for a good standalone proposal -- both because it's complex enough to deserve its own discussion, and because if the community is interested someone would have to work through all the implications in order to put together a proposal. It would be quite a big change.
>>> 
>>> I don't see how this is different from a protocol other than the lack of requirement to declare conformance explicitly.  The need to explicitly declare conformance is a design decision that I believe the core team feels pretty strongly about.  
>>> 
>>> That said, it hasn't been debated by the community yet so if someone feels strongly about dropping explicit conformance declarations it might be worth pitching the idea, if for not other reason than to have a discussion about it on the lost.
>> 
>> I don’t see any desire to follow Go’s path here and drop explicit conformance in any way.
>> 
>> Basically such `existential` mechanism could express more than `Any<…>` could. That said I do feel that this "could“ have some potential to exist alongside `Any<…>`.
>> 
>> 
> 
> Anything “more” it could express would be specific member requirements, which would make it in some sense ad-hoc protocol.  I would rather see one mechanism for defining member requirements.  We already have that and it is called a protocol.
> 
> The reason types won’t need to declare explicit conformance to an `Any` is that the requirements of the `Any` are composed of an optional supertype as well zero or more protocol and associated type constraints.  The “conformance" of a type to the `Any` is defined by its conformance to the protocols that the `Any` is composed of.  
> 
> If you want to introduce new requirements the right way to do it is to declare an additional protocol and add it to the list of protocol constraints in the `Any`.
>> From my understanding of this whole existential type thing is that it can be used both ways, explicitly and implicitly. As said before we only discussed the explicit existential types.
>> 
>> 
>> 
>> Just another pseudo example:
>> 
>> ```swift
>> 
>> // this could also replace typealiases for (generic) existentials
>> 
>> 
> 
> I gave some consideration to scoped syntax like this a few days ago.  The problem with it is that `Any` is a structural type defined by the constraints and this makes it look like a nominal type.  

I am not sure I follow you.. If Any is a structural type, then case closed, it is instantiate-able and carry all the normal behavior of all other structural types. Or is it a wolf in sheep's clothing that is actually neither a wolf, nor a sheep?

This is ultimately coming back to my earlier question of how does one differentiate between  X<...>   and Y<...>? 

Should we read the angle brackets first and reach the logical (but wrong) conclusion that X and Y will essentially behave in a similar fashion, or should we read the names first and remember that we have to go to two different pages of the swift programmer's guide to make sense of what follows?

As was previously said with great eloquence (i believe by Joe Groff), Any<> is something only a compiler loves... I would like it if we found something both the swift compiler and the swift programmer could love.


> 
> If you define two “existential” types with the exact same constraints under different names, what happens?  They should be identical to other any equivalent formulation and that is clear under Austin’s proposal, but because this alternative looks like a nominal type you might have the expectation that the types are independent of each other.  That is why typealias is the correct solution here IMO.  It is clear that the name is just an alias for a structural type.
>> existential CrazyView  {
>> 
>>     // we could introduce a way for constraints which could have a nice looking syntax
>> 
>>     // break `Any<…>` nesting and long very long composition lines of `Any<…>` 
>> 
>>     constraint Any<UIScrollView, Any<UITableView, Any<UIView, ProtocolA>>>
>> 
>>     constraint ProtocolA.AssociatedType == Int 
>> 
>>     func crazyFunction()
>> 
>> }
>> 
>> 
>> 
>> existential AnyCollection<T>  {
>> 
>>    constraint Collection
>> 
>>    constraint Collection.Element == T
>> 
>> }
>> 
>> ```
>> 
>> But I don’t want to go any further if there is no need (yet).
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/24e28f81/attachment.html>


More information about the swift-evolution mailing list