[swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng]

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. 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.

Best,
Austin

On Thu, May 26, 2016 at 11:56 AM, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
> <https://en.wikipedia.org/wiki/Type_system#Existential_types> 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
>
>
> _______________________________________________
> 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/20160526/e4731403/attachment.html>