[swift-evolution] Enhanced existential types proposal discussion

[Adrian Zubarev]

Good point. :)

I’ve been thinking if there is a way to still have a shiny and swifty looking syntax which would solve this problem:

typealias SomeExistential<T> = existential<T> {

    constraint UIView
    constraint ProtocolA     
    constraint ProtocolB.AssociatedType == T
     
    var someVar: Int { get set }
}
This mimics typealias Name = protocol<…> where the protocol<…> does not have an explicit name.

One downside of this approach:

To use such an existential you would need give it a name trough typealias.
typealias AnyCollection<T> = existential<T> {

   constraint Collection
   constraint Collection.Element == T
}


-- 
Adrian Zubarev
Sent with Airmail

Am 26. Mai 2016 bei 22:56:10, Matthew Johnson (matthew at anandabits.com) schrieb:


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.  

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

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