it against potential witnesses, make sure to use the unlabeled form of
the substituted type. Otherwise, tuples with element names in the
return type will break us. Fixes <rdar://problem/11598297>.
Swift SVN r2156
only one protocol, just use that as the existential type rather than
unnecessarily wrapping it in protocol<>. This is just for simplicity.
Swift SVN r2140
protocols it conforms to. Use this list when substituting into a
protocol's signature, so that we get an existential type back. For
example:
var e : Enumerable
var r = e.getElements()
r.getFirstAndAdvance() // okay: r is a range.
Swift SVN r2139
protocols the underlying type of the type alias shall conform to. This
isn't super-motivating by itself (one could extend the underying type
instead), but serves as documentation, makes typealiases provide the
same syntax as other nominal types in this regard, and will also be
used to specify requirements on associated types.
Swift SVN r2133
type is either a protocol type or a protocol composition type. The
long form of this query returns the minimal set of protocol
declarations required by that existential type.
Use the new isExistentialType() everywhere that we previously checked
just for ProtocolType, implementing the appropriate rules. Among other
things, this includes:
- Type coercion
- Subtyping relationship
- Checking of explicit protocol conformance
- Member name lookup
Note the FIXME for IR generation; we need to decide how we want to
encode the witnesses for the different protocols.
This is most of <rdar://problem/11548207>.
Swift SVN r2086
protocol conformance types, e.g., 'protocol<P, Q>'. A few things
people *might* want to scream about, or at least scrutinize:
- The parsing of the '<' and '>' is odd, because '<' and '>' aren't
tokens, but are part of the operator grammar. Neither are '>>',
'>>>', '<>', etc., which also come up and need to be parsed
here. Rather than turning anything starting with '<' or '>' into a
different kind of token, I instead parse the initial '<' or '>'
from an operator token and leave the rest of the token as the
remaining operator.
- The canonical form of a protocol-composition type is minimized by
removing any protocols in the list that were inherited by other
protocols in the list, then sorting it. If a singleton list is
left, then the canonical type is simply that protocol type.
- It's a little unfortunate that we now have two existential types
in the system (ProtocolType and ProtocolCompositionType), because
many places will have to check both. Once ProtocolCompositionTypes
are working, we should consider whether it makes sense to remove
ProtocolType.
Still to come: name lookup, coercions.
Swift SVN r2066
oneof's type, not the type we're trying to infer. This matches the diagnostic.
- Fix the diagnostic produced by visitUnresolvedMemberExpr when we find
a non-function element but expect a function, to say so.
- Fix coercing in visitUnresolvedDotExpr to handle the case when we do infer a
type for the result of the UnresolvedDotExpr. Even though it isn't helpful, it
isn't a bad thing to infer things :)
- Fix the logic that I added in an if(0) block to SemaCoerce::visitApplyExpr to
preserve the "CF_Apply" bit. Dropping this is bad.
- Move this logic around a bit and enable it! This allows zapping some terrible
"syntactic" processing of UnresolvedMemberExpr, and a fixme.
The terrible "syntactic" handling of OverloadSetRefExpr will die next.
Swift SVN r2011
It still doesn't work for fully unstructured unresolved types.
- Enhance contextual resolution of UnresolvedMemberExpr to handle types like Unresolved->SomeOneOf.
- Enhance overload set resolution to work with types like "Unresolved->SomeTy", though this
implementation is seems dubious to me and ignores type information that we have about the argument
type. I'd like to require the argument to also be a subtype, but I need to teach isSubtypeOf about
unresolved types. I'd love review of this code from someone.
- Add an if(0)'d out blob of code (which is close but not completely right) that handles coercing
of applys with structure inference instead of syntactic inference, which will ultimately zap a
bunch of code and some FIXMEs.
Swift SVN r2008
values of existential type, e.g.,
var x : Printable
x.print()
Existential member references reify the type of the implicit object
argument (implicitly, because we have no way of expressing this in the
type system), and replace the types of any other archetypes
with existential types that (don't, but will eventually) conform to
the protocols to which the archetypes conform.
Swift SVN r1963
using the term "unresolved" in expressions for a while, and it fits
for types better than "dependent type."
The term "dependent type" will likely come back at some point to mean
"involves an archetype".
Swift SVN r1962
Range protocol, rather than using an informal protocol. This is most
of <rdar://problem/11475213>, although we still use an informal
protocol for the initial 'getElements()' call because we don't yet
have the ability to add requirements to associated types.
Swift SVN r1961
unsatisfied associated type requirements. Otherwise, we would assert
because substitution did not have a binding for the unsatisfied
archetypes. This whole conforms-to matching stuff will eventually be
rewritten, so it doesn't bother me that we don't continue checking
very far after failing to satisfy an associated type requirement.
Swift SVN r1958
the unlabeled types rather than labeled types. It's ridiculous to
require the same parameter names (although one could perhaps use them
as a tie-breaker).
Swift SVN r1956
archetypes. Use this substitution when checking the
variable/function/subscript witnesses during protocol conformance.
This allows us to check the conforms-to relationship for the Range
protocol as we want to express it.
Swift SVN r1945
