classes, with the same syntax as we have on protocols. This
inheritance specifies explicit conformance to a protocol.
Later, we can allow a class definition to have a single class type
within this list, when we introduce class inheritance.
Swift SVN r1862
[byref(implicit)], and rely on type coercion for the implicit object
argument to deal with the implicitness. This is one half of
<rdar://problem/11215969>.
The other half of <rdar://problem/11215969> requires us to invent some
syntax to allow increment/decrement/assignment to operate on lvalues
without requiring one to write '&'. There are two distinct ideas
gaining traction here:
- Adding an [assignment] attribute to these operators, which tells
us both that use of the operators is a statement (not an
expression) and that the byref argument (either on the left, or
the only argument).
- Allowing operators to be written as member functions, so that they
get the same treatment as "a.b".
The former seems like the better option.
Swift SVN r1819
from a protocol to a protocol it inherits. This is a far simpler
operation that the general type-erasure expression, so generate this
AST when we can.
Swift SVN r1813
protocol Document { var title : String }
protocol Versioning { func bumpVersion() }
protocol VersionedDocument : Document, Versioning { }
This commit covers the basic functionality of protocol inheritance, including:
- Parsing & AST representation
- Conforming to a protocol also requires conforming to its inherited
protocols
- Member lookup into a protocol also looks into its inherited
protocols (results are aggregated; there is no name hiding)
- Teach ErasureExpr to maintain lvalueness, so we don't end up
performing a silly load/erase/materialize dance when accessing
members from an inherited protocol.
Swift SVN r1804
provide a mapping back to that variable. Teach the mangler to provide
a special mangling for such functions (__getVarName,
__setVarName). The mangling will undoubtedly change later, but the
point is that it will need to match the functions generated for
a resilient variable.
Swift SVN r1432
PatternBindingDecl to the DeclContext. Do the same for the get/set
functions for a property, so we don't need to perform 'deep' setting
of the DeclContext. This is simpler, although it makes pretty-printing
the AST a bit more difficult.
Swift SVN r1428
struct/oneof/class extension, making them instance methods. Normal
variables are still not allowed in these contexts, however.
The fact that we set DeclContexts late causes some consternation here,
because it's not clear just how far we need to recurse in
DeclContext. I've done enough to make properties work, but I'm still
rather uneasy about the current state of affairs.
Swift SVN r1423
syntax when name lookup finds multiple candidates. Overload resolution
is then used to select the best candidate and map the overloaded
member reference expression down to DotSyntaxCallExpr or
DotSyntaxBaseIgnoredExpr, as appropriate.
This implements part of <rdar://problem/11071641>, so that simple
overload resolution works, but there is still a bit of cleanup to do.
Swift SVN r1366
type with one or more elements of dependent type. Previously, an
expression such as (x, 5) would have the (unstructured) dependent
type, limiting our ability to type-check the subexpression 'x'
early. Now, if 'x' has type 'int' (for example), this expression will
now have the type (int, <<unstructured dependent type>>).
Extend coercion of a tuple to tuple type to handle coercion to
(structured) dependent tuple types, coercing element-by-element. This
code is very lightly tested and may still need to be restructured.
Swift SVN r1294
qualifier, making sure that variables end up so-qualified by
default. Add a RequalifyExpr to capture the act of adding
qualifiers (to form a supertype) to an l-value.
Swift SVN r1236
- introduce the concept of qualifiers on l-value types
- teach overload resolution and coercion how to drop explicitness
- require explicitness on normal [byref] arguments
- make 'this' [byref(implicit)]
- special-case '&' as a unary operator in the parser to make it
produce an expression which type-checks as turning implicit l-values
into explicit ones.
Obvious missing pieces:
- updating LangRef
- we should really complain about ever trying to rvalue-convert an
explicit l-value
- maybe qualification should play a part in overload resolution
- we should diagnose attempts to declare unary '&' operators
- there's a test case in expressions.swift which suggests my logic is
slightly off
But I am out of time, and these will have to wait.
Swift SVN r1119
After some pondering on this, I can just use DeclRefExpr(TypeAliasDecl) to
represent a named metatype, there is not need to have yet-another decl. I'm
glad about this, because it didn't seem right.
Swift SVN r999
