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?

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?

I agree that your example should work -- the rules for patching method overrides and protocol witnesses are more stringent than they need to be. There's an interesting engineering challenge in generalizing the logic and also cleaning it up to share as much code as possible with the subtype matching code in the constraint solver.

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?

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?

So it seems like you would expect it to work as I thought it should. However, from reading the language reference
there is no mention of whether derived types are conforming types and there are no examples shown that demonstrate this either.

Can someone who knows verify whether this is a bug, or an oversight or as designed?

The workaround for me is to move everything in the base class which neuters the type system somewhat.

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?

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.

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.

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.

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.

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.