Commit Graph

1 Commits

Author SHA1 Message Date
Doug Gregor
c079874625 Implement parsing, AST, type canonicalization, and type validation for
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
2012-05-30 00:39:08 +00:00