[swift-evolution] Allow protocol vars to match derived types

Mark Anders mark at markanders.net
Tue Mar 8 15:15:59 CST 2016


Slava/Joe, thanks for clarifying the issue and Slava for providing more depth on what needs to happen. Like David, I was unsure if this was just a bug or an enhancement.

Out of curiosity, you mention some related issues, and I just ran into something similar and wonder if it’s related too.

class A {}
class B : A {}

var arrayOfA = [A]()
let arrayOfB : [B] = [B()]
arrayOfA.appendContentsOf(arrayOfB)

This fails to compile, though doing arrayOfA.append(B()) works as I would expect.

Is it related?  In general, it seems that Swift’s type system is stricter than I would expect.

Do these types of issues seem in-scope for Swift 3?

Mark

On March 8, 2016 at 1:22:13 AM, Slava Pestov via swift-evolution (swift-evolution at swift.org) wrote:

I would suggest a formal proposal because its a bit involved I think. It should ideally match the subtyping rules, so

- A matches B if A is a subclass of B
- A matches P if A conforms to P
- A matches A?
- A! matches A? and vice versa
- T1 -> U1 matches T2 -> U2 if T2 is a subtype of T1 and U1 is a subtype of U2
- some rules for ‘throws’ functions

I think there might be some tricky cases with associated type inference. We should be careful not to break any existing code.

Also a related proposal would be to allow enum cases to witness static method requirements, and methods to witness property requirements of function type and vice versa, but these seem less useful.

Code for matching witnesses is in TypeCheckProtocol.cpp, and override matching is elsewhere (I think Decl.cpp in lib/AST/)? Take a look if you’re curious about what the rules are today.

Slava

On Mar 7, 2016, at 11:06 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:

If it’s an obvious omission, is it better to have it as a bug than a formal proposal?

On 08 Mar 2016, at 00:16, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:


On Mar 7, 2016, at 8:12 AM, Mark Anders via swift-evolution <swift-evolution at swift.org> wrote:

Consider the following (you can paste it in a Playground to see the error):

class Node { }
class Containable : Node{}

protocol Refers {
    var to : Node {get}
}

class Link : Refers {
    var to : Node
    init(n : Node) {
        to = n
    }
}

class Contains : Refers {
    var to : Containable
    init(c : Containable) {
        to = c
    }
}

This currently does not work because it seems that to adopt a protocol, the type of protocol var must match exactly.

It would be great if objects could be said to adopt a protocol if the type of the var is the type or a derived type.  
This would allow me to treat the structure in a type safe way (i.e. only a Containable can have a Contains relationship), 
while me to have a set of Refers and iterate through each Node.

Is there a reason why the type must match exactly?  Or could protocols be enhanced to to allow matching
derived types, similar to assignment and func parameter rules?  

No fundamental reason, this just isn't something we've had time to implement. It should be straightforward to support.

-Joe
_______________________________________________
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

_______________________________________________
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/20160308/257e2252/attachment.html>


More information about the swift-evolution mailing list