When a specialization of a generic type occurs within the signature of
a generic function, it implies that the generic arguments meet the
requirements of the generic type. For example, in
func printHashes<K, V>(dict : Dictionary<K, V>) {
for (k, v) in dict {
print("\(k.hashValue())\n")
}
}
the presence of Dictionary<K, V> in the signature implies that K and V
meet the requirements on Dictionary's generic parameters, i.e., that K
is Hashable. Thus, infer that K is Hashable in printHashes().
Fixes the easy part of <rdar://problem/14691708>. Same-type and
superclass requirements are more interesting.
<rdar://problem/14691708>
Swift SVN r7574
When checking a type's conformance against a protocol, we can deduce
the values of associated types. Make these associated types visible to
qualified name lookup so that (for example) VectorEnumeratorType does
not need to define the Element type. It is deduced from the signautre
of next(), and made available as, e.g.,
VectorEnumeratorType<Int>.Element through the Enumerator protocol
conformance. Fixes <rdar://problem/11510701>, but with some lingering
dependencies on lazy type resolution (<rdar://problem/12202655>).
Note that the infrastructure here is meant to be generalized to
support default implementations in protocols, but there are several
pieces still not in place.
Swift SVN r6073
This change enables inheritance constraints such as "T : NSObject",
which specifies that the type parameter T must inherit (directly or
indirectly) from NSObject. One can then implicit convert from T to
NSObject and perform (checked) downcasts from an NSObject to a T. With
this, we can type-
IR generation still needs to be updated to handle these implicit
conversions and downcasts. New AST nodes may follow.
Swift SVN r3459
Add a couple other misc pieces necessary for semantic analysis of members of
generic types. We're now up to the point where we can actually construct a
useful AST for small testcases.
Swift SVN r2308
coercion. Overload resolution uses this argument deduction when
dealing with generic functions, to determine when we can invoke a
generic function. When a generic function is selected, we create a
SpecializeExpr wrapping the DeclRefExpr to the generic function.
This is sufficient to type-check calls to simple things like a call to
func identity<T>(x : T) -> T { return x }
with a value of known type. However, it's missing far too many pieces
to enumerate.
Swift SVN r2230
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
introduce the generic type parameters (which are simply type aliases
for a to-be-determined archetype type) into scope for name
lookup. We can now parse something like
func f<T, U : Range>(x : T, y : U) { }
but there is no semantic analysis or even basic safety checking (yet).
Swift SVN r2197
