The proposal SE-0267, where
clauses on contextually generic declarations, has been accepted.
Could anyone elaborate more on what this part means?
This would continue not to be allowed:
class C {
// would create a method that only existed on subclasses that conform to Equatable
func foo() where Self: Equatable { ... }
}
class G<T> {
// would create a method that only existed on some instances
func foo() where T: Equatable { ... }
}
I am not sure I follow with the second one? We can already write equivalent generic methods and override them with compatible signatures:
class Class<T> {
func foo<U>(arg: U) where T: Equatable { ... }
}
class Sub<T>: Class<T> {
override func foo<U>(arg: U) {} // OK
}
According to @Douglas_Gregor, that isn't intended to be accepted either.
Oh, hm. It would be unfortunate to ban these overrides altogether now that we happen to allow them for generic methods, especially since they seem to work correctly thanks to @suyashsrijan fixing the bug where generic signatures were ignored during matching (I've updated override matching to account for contextually generic methods too right before I asked about this).
@Douglas_Gregor What do you think? Would it be alright to let the feature live for a while until Suyash or I run it through the Evolution process?
Does it mean the generic signatures have to be the same when overriding? We generate a thunk when base method generic requirements are not satisfied by the derived method.
Worse, it means any method with a requirement on an outer generic parameter in its generic signature was intended to either be
final
- declared in a
final
class - declared in an extension of a non-final class
Basically anything that prevents an override.
Specifically, generic requirements that limit the Self
type so that the method isn't available for all instances of the class are what we expected to be disallowed. If they're already accepted, and work as expected, maybe it's OK.