There's no good reason to permit them. Conformances like Copyable and
Sendable are pervasive, so it's as though we are permitting extensions
of `Any`. Until there's a good argument in favor of such extensions,
remove the capability now.
If the 'self' type is abstract, we still have to consider it as
a source of type metadata, because it might be a class-bound
generic parameter and the class might have generic parameters.
Fixes <rdar://problem/36093833>.
Previously protocol extension initializers which called 'self.init' were
considered 'delegating', and ones that assign to 'self' were considered
'root'.
Both have the same SIL lowering so the distinction is not useful, and
removing it simplifies some code.
Consider the following code:
protocol P {
func foo<A>(_: A)
}
extension P {
func foo<A>(_: A) {}
}
class C<T> : P {}
Before, the witness thunk for [C : P].foo() had the generic signature
<T, A>, and the witness P.foo() was called with a substitution
Self := C<T>.
This is incorrect because the caller might be using a subclass of C
as the 'Self' type, but this was being erased.
Now, the witness thunk for [C : P].foo() has the generic signature
<X : C<T>, T, A>, and the witness P.foo() is called with the
substitution Self := X.
Fixes <rdar://problem/33690383>, <https://bugs.swift.org/browse/SR-617>.
Consider the following code:
protocol P {
func foo<A>(_: A)
}
extension P {
func foo<A>(_: A) {}
}
class C<T> : P {}
Before, the witness thunk for [C : P].foo() had the generic signature
<T, A>, and the witness P.foo() was called with a substitution
Self := C<T>.
This is incorrect because the caller might be using a subclass of C
as the 'Self' type, but this was being erased.
Now, the witness thunk for [C : P].foo() has the generic signature
<X : C<T>, T, A>, and the witness P.foo() is called with the
substitution Self := X.
Fixes <rdar://problem/33690383>, <https://bugs.swift.org/browse/SR-617>.
Judging from history, the original tests appear to just be attempts to
flesh out test coverage rather than specific regression tests, and the
features in question are well-covered by other tests.
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976