Considering how I interpret (i.e. I could be totally wrong) sentiments 
expressed by the core team on expressiveness, I would wager that duck typing is 
NOT on their agenda for Swift.


> On May 26, 2016, at 8:56 PM, Adrian Zubarev via swift-evolution 
> <[email protected]> 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 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to