[swift-evolution] Enhanced existential types proposal discussion

Adrian Zubarev adrian.zubarev at devandartist.com
Thu May 26 13:56:57 CDT 2016

I’d like to throw one idea of mine in the room I couldn’t stop thinking when I read one of Thorsten’s replies on SE–0095 review thread.

This wiki section explains the existential types where we have something like this:

"T = ∃X { a: X; f: (X → int); } This could be implemented in different ways; for example:

intT = { a: int; f: (int → int); }
floatT = { a: float; f: (float → int); }
We discussed how we could create existential types with constraints for protocols and classes so far. Such an existential can’t create something like in the example above.

I’m not sure if we need this at all, I’d say it’s a nice to have idea of mine.

To solve this we could introduce a new scope similar to protocols today but without the need to explicitly conform types to this existential.

// the above example can become
existential T {
    associatedtype X
    var a: X
    func f(_ value: X) -> Int

struct A /* no explicit conformance to T needed */ {
    var a: Int
    init(a: Int) { self.a = a }
    func f(_ value: Int) -> Int { return value }

let store: T = A() // this could or should work, just because we do have visibility to all constraints from T in A here

// if we had `private var a: Int` in A we wouldn't be able to store A inside `store`
I din’t though if existential could have potential to replace Any<…> completely. Until now I just wanted to solve that particular issue so please don’t judge with me. :)

Just because of associated types we won’t be able to use store in this example, but there might be more trivial examples where one would use such existential type (for only visible portion at compile or dynamically at run-time) without explicit conformance.

struct B {
    var x: Int = 42
    var y: Double = -100.5

struct C: SomeProtocol {
    var y: Double = 0.0
    var x: Int = 10

existential SomeShinyThing {
    var x: Int
    var y: Double

// we should be safe here because the compiler has visibility for  
// internal B and C here
let anotherStore: SomeShinyThing = B() /* or */ C()  

// otherwise one could use dynamic casts
if let thirdStore = instanceOfCShadowedAsSomeProtocol as? SomeShinyThing { … }
Feel to tear this idea apart as you want. :D

Adrian Zubarev
Sent with Airmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160526/1f7176ed/attachment.html>

More information about the swift-evolution mailing list