applies to operators whose first parameter is [byref]. Assignments
must return Void, and have their first arguments implicitly treated as
an lvalue.
As part of this, add the various C compound operators (+=, -=, *=, /=,
&=, |=, and ^=) to the standard library.
Swift SVN r1846
another function type, so long as the source is a subtype of the
target. The subtyping relation is fairly obvious, allowing parameter
renaming, qualification conversions for lvalue types, and
protocol-conformance conversions (at the top level of function
types). It is a strict subset of the allowed type coercions.
The representation of FunctionConversionExpr is temporary. It will
need to account for the capture of the source of the conversion in the
trivial-trivial case.
Swift SVN r1839
in general, not sound. For the limited cases where we did use this
expression kind on lvalues (member access or instance method
invocations on a superprotocol), leave the conversion to the client of
their respective AST nodes (MemberRefExpr, DotSyntaxCallExpr). We may
decide to enrich these ASTs in the future with more information about
the conversion path, but it's not clear that it's actually useful
information for, e.g., IRgen.
Swift SVN r1830
[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
I'm not completely sure this is the representation we want, but it isn't much code to rip out if we decide to represent it some other way.
While I'm in the area, also fix a case where tuple->tuple conversion wasn't working.
Swift SVN r1748
e.g. "foo is \(i+j)". This implements rdar://11223686
Doug implemented all the hard parts of this. I ripped out support for nested string
literals (i.e. string literals within an interpolated string), which simplified the
approach and defined away some problems with his patch in progress. I plan a few refinements
on top of this basic patch.
Swift SVN r1738
implementing rdar://11360347 / 11349750. C-style for loops could be
further enhanced by allowing a comma-separated list of statements in
the increment, but this isn't something I plan to do in the short term.
Swift SVN r1713
multiple times, as well as teaching the name lookup mechanism that
it's similarly rude to report ambiguous results because it searched
the same import twice. Fixes <rdar://problem/11287213>.
Yes, this is a bit of an ugly hack.
Swift SVN r1610
