When checking for permitted uses of Self in the input type of a
protocol requirement's function type, if the parameter itself was
a function we would recurse into its input, and reject all uses
of Self in the parameter type's result. This was the wrong way
around, and in fact we should recurse into the result.
Here is a test case that used to compile successfully and crash;
now it is rejected by the type checker:
protocol P {
func f(a: Self -> ())
}
protocol Q : P {
func g()
}
class C : P {
func f(a: C -> ()) { // should not be allowed to witness P.f
a(C())
}
}
class B : C, Q {
var x: Int = 17
func g() {
print(x)
}
}
func f<T : Q>(t: T) {
// T == B here
// t.f has type <T : Q> (T -> ()) -> ()
t.f({ $0.g() }) // but at runtime, $0 is a C not a B
}
f(B())
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
When a non-final class satisfies a method requirement that returns
Self, it must do so with a method that also returns (dynamic)
Self. This ensures conformance will be inheritable, closing off an
awful type-safety hole <rdar://problem/16880016>. Other
non-contravariant uses of Self in the signatures of requirements cause
the protocol to be unusable by non-final classes.
I had to leave a tiny little gaping hole for the ~> operator, whose
removal is covered by <rdar://problem/17828741>. We can possibly put
this on firm footing with clever handling of generic witnesses, but
it's not important right now.
Swift SVN r20626
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
Better to describe how the protocol can be used than how it can't. Also include a mention of Self type requirements as a source of non-existentiability.
Swift SVN r19207
These types are often useless and confusing to users who expect to be able to use Sequence or Generator as types in their own right like in C# or Java. While we're here, relax the rules for self-conformance to admit methods returning 'Self'. Covariant return types should not actually prevent a protocol type from conforming to itself, and the stdlib makes particular use of protocols with 'init' requirements which implicitly return Self.
Swift SVN r18989
'Self' can be used within parameters whenever the corresponding
parameter in a subclass will be contravariant, and in result types
when the method returns dynamic Self. This also applies to subscript
indices. More of <rdar://problem/16996872>.
Swift SVN r18788
A protocol conformance of a class A to a protocol P can be inherited
by a subclass B of A unless
- A requirement of P refers to Self (not an associated type thereof)
in its signature,
+ *except* when Self is the result type of the method in P and the
corresponding witness for A's conformance to B is a DynamicSelf
method.
Remove the uses of DynamicSelf from the literal protocols, going back
to Self. The fact that the conformances of NSDictionary, NSArray,
NSString, etc. to the corresponding literal protocols use witnesses
that return DynamicSelf makes NSMutableDictionary, NSMutableArray,
NSMutableString, and other subclasses still conform to the
protocol. We also correctly reject attempts to (for example) create an
NSDecimalNumber from a numeric literal, because NSNumber doesn't
provide a suitable factory method by which any subclass can be literal
convertible.
Swift SVN r14204