averello/swift-mirror
1
0
Fork 0
mirror of https://github.com/apple/swift.git synced 2025-12-21 12:14:44 +01:00
Code Issues Packages Projects Releases Wiki Activity
Files
d40f74f2c10d6750e0751cd387dcf9d81617aa5f
swift-mirror/docs/LangRef.html
Jordan Rose d40f74f2c1 [Parse] Treat ! as a postfix operator when both left- and right-bound. 
For most operators, an expression like "a@b" is lexed with '@' as a binary
operation on 'a' and 'b'. However, we want to make sure we can support
calling optional functions using the syntax "a!()". Consequently, if there
are no spaces around a single '!' token, it is treated as a postfix operator
instead of an infix operator. The infix interpretation can still be requested
by using spaces on both sides of the operator.

Swift SVN r7651
2013-08-28 00:18:19 +00:00

3708 lines
146 KiB
HTML
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Swift Language Reference Manual</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="author" content="Chris Lattner">
<meta name="description"
content="Swift Language Reference Manual.">
<link rel="stylesheet" href="_static/swift.css" type="text/css">
<script type="text/javascript" src="toc.js"></script>
</head>
<body>
<h1>Swift Language Reference</h1>
<p>
<!-- The Table of Contents is automatically inserted in this <div>.
Do not delete this <div>. -->
<div id="nav"></div>
</p>
<!-- ********************************************************************* -->
<h2>Introduction</h2>
<!-- ********************************************************************* -->
<div class="commentary">
In addition to the main spec, there are lots of open ended questions,
justification, and ideas of what best practices should be. That random
discussion is placed in boxes to the right side of the main text (like this
one) to clarify what is normative and what is discussion.
</div>
<p>This is the language reference manual for the Swift language, which is
highly volatile and constantly under development. As the prototype evolves,
this document should be kept up to date with what is actually implemented.</p>
<p>The grammar and structure of the language is defined in BNF form in yellow
boxes. Examples are shown in gray boxes, and assume that the standard library
is in use (unless otherwise specified).</p>
<!-- ===================================================================== -->
<h3>Basic Goals</h3>
<!-- ===================================================================== -->
<div class="commentary">
A non-goal of the Swift project in general is to become some amazing
research project. We really want to focus on delivering a real product,
and having the design and spec co-evolve.
</div>
<p>In no particular order, and not explained well:</p>
<ol>
<li>Support building great frameworks and applications, with a specific focus
on permiting rich and powerful APIs.</li>
<li>Get the defaults right: this reduces the barrier to entry and increases
the odds that the right thing happens.</li>
<li>Through our support for building great APIs, we aim to provide an
expressive and productive language that is fun to program in.</li>
<li>Support low-level system programming. We should want to write compilers,
operating system kernels, and media codecs in Swift. This means that being
able to obtain high performance is really quite important.</li>
<li>Provide really great tools, like an IDE, debugger, profiling, etc.</li>
<li>Where possible, steal great ideas instead of innovating new things that
will work out in unpredictable ways. It turns out that there are a lot
of good ideas already out there.</li>
<li>Memory safe by default: array overrun errors, uninitialized values,
and other problems endemic to C should not occur in Swift, even if it
means some amount of runtime overhead. Eventually these checks will be
disablable for people who want ultimate performance in production
builds.</li>
<li>Efficiently implementable with a static compiler: runtime compilation is
great technology and Swift may eventually get a runtime optimizer, but it
is a strong goal to be able to implement swift with just a static
compiler.</li>
<li>Interoperate as transparently as possible with C, Objective-C, and
C++ without having to write an equivalent of "extern C" for every
referenced definition.</li>
<li>Great support for efficient by-value types.</li>
<li>Elegant and natural syntax, aiming to be familiar and easy to transition
to for "C" people. Differences from the C family should only be done when
it provides a significant win (e.g. eliminate declarator syntax).</li>
<li>Lots of other stuff too.</li>
</ol>
<p>A smaller wishlist goal is to support embedded sub-languages in swift, so
that we don't get the OpenCL-is-like-C-but-very-different-in-many-details
problem.</p>
<!-- ===================================================================== -->
<h3>Basic Approach</h3>
<!-- ===================================================================== -->
<div class="commentary">
Pushing as much of the language as realistic out of the compiler and into
the library is generally good for a few reasons: 1) we end up with a smaller
core language. 2) we force the language that is left to be highly
expressive and extensible. 3) this highly expressive language core can then
be used to build a lot of other great libraries, hopefully many we can't
even anticipate at this point.
</div>
<p>The basic approach in designing and implementing the Swift prototype was to
start at the very bottom of the stack (simple expressions and the trivial
bits of the type system) and incrementally build things up one brick at a
time. There is a big focus on making things as simple as possible and
having a clean internal core. Where it makes sense, sugar is added on top
to make the core more expressive for common situations.</p>
<p>One major aspect that dovetails with expressivity, learnability, and focus
on API development is that much of the language is implemented in a <a
href="#stdlib">standard library</a> (inspired in part by the Haskell
Standard Prelude). This means that things like 'Int' and 'Void' are not
part of the language itself, but are instead part of the standard library.
</p>
<!-- ********************************************************************* -->
<h2>Phases of Translation</h2>
<!-- ********************************************************************* -->
<div class="commentary">
Because Swift doesn't rely on a C-style "lexer hack" to know what is a type
and what is a value, it is possible to fully parse a file without resolving
import declarations.
</div>
<p>Swift has a strict separation between its phases of translation, and the
compiler follows a conceptually simple design. The phases of translation
are:</p>
<ul>
<li><a href="#lexical">Lexing</a>: A translation unit is broken into tokens
according to a (nearly, /**/ comments can be nested) regular grammar.</li>
<li>Parsing and AST Building: The tokens are parsed according to the grammar
set out below. The grammar is context free and does not require any "type
feedback" from the lexer or later stages. During parsing, name binding for
references to local variables and other declarations that are not at
translation unit (and eventually namespace) scope are bound.
</li>
<li><a href="#namebind">Name Binding</a>: At this phase, references to
non-local types and values are bound, and <a href="#decl-import">import
directives</a> are both validated and searched. Name binding can cause
recursive compilation of modules that are referenced but not yet built.
</li>
<li><a href="#typecheck">Type Checking</a>: During this phase all types are
resolved within value definitions, <a href="#expr-call">function
application</a> and <a href="#expr-infix">binary expressions</a> are found
and formed, and overloaded functions are resolved.</li>
<li>Code Generation: The AST is converted the LLVM IR, optimizations are
performed, and machine code generated.</li>
<li>Linking: runtime libraries and referenced modules are linked in.</li>
</ul>
<p>
FIXME: "import swift" implicitly added as the last import in translation unit.
</p>
<!-- ********************************************************************* -->
<h2 id="lexical">Lexical Structure</h2>
<!-- ********************************************************************* -->
<div class="commentary">
Not all characters are "taken" in the language, this is because it is still
growing. As there becomes a reason to assign things into the identifier or
punctuation bucket, we will do so as swift evolves.
</div>
<p>The lexical structure of a Swift file is very simple: the files are
tokenized according to the following productions and categories. As is
usual with most languages, tokenization uses the maximal munch rule and
whitespace separates tokens. This means that "a b" and "ab" lex into
different token streams and are therefore different in the grammar.</p>
<!-- ===================================================================== -->
<h3 id="whitespace">Whitespace and Comments</h3>
<!-- ===================================================================== -->
<div class="commentary">
Nested block comments are important because we don't have the nestable
"#if 0" hack from C to rely on.
</div>
<pre class="grammar">
whitespace ::= ' '
whitespace ::= '\n'
whitespace ::= '\r'
whitespace ::= '\t'
whitespace ::= '\0'
comment ::= //.*[\n\r]
comment ::= /* .... */
</pre>
<p>Space, newline, tab, and the nul byte are all considered whitespace and are
discarded, with one exception: a '(' or '[' which does not follow a
non-whitespace character is different kind of token (called
<em>spaced</em>) from one which does not (called <em>unspaced</em>).
A '(' or '[' at the beginning of a file is spaced.</p>
<p>Comments may follow the BCPL style, starting with a "//" and running to the
end of the line, or may be recursively nested /**/ style comments. Comments
are ignored and treated as whitespace.</p>
<!-- ===================================================================== -->
<h3 id="reserved_punctuation">Reserved Punctuation Tokens</h3>
<!-- ===================================================================== -->
<div class="commentary">
The difference between reserved punctuation and identifiers is that you
can't "overload an operator" with one of these names.<br><br>
Note that -&gt; is used for function types "() -&gt; Int", not pointer
dereferencing.
</div>
<pre class="grammar">
punctuation ::= '('
punctuation ::= ')'
punctuation ::= '{'
punctuation ::= '}'
punctuation ::= ']'
punctuation ::= ']'
punctuation ::= '.'
punctuation ::= ','
punctuation ::= ';'
punctuation ::= ':'
punctuation ::= '='
punctuation ::= '-&gt;'
punctuation ::= '...'
punctuation ::= '&amp;' // unary prefix operator
</pre>
<p>These are all reserved punctuation that are lexed into tokens. Most other
punctuation is matched as <a href="#identifier">identifiers</a>.
</p>
<!-- ===================================================================== -->
<h3>Reserved Keywords</h3>
<!-- ===================================================================== -->
<div class="commentary">
The number of keywords is reduced by pushing most functionality
into the library (e.g. "builtin" datatypes like 'Int' and 'Bool'). This
allows us to add new stuff to the library in the future without worrying
about conflicting with the user's namespace.
</div>
<pre class="grammar">
// Declarations and Type Keywords
keyword ::= 'class'
keyword ::= 'constructor'
keyword ::= 'destructor'
keyword ::= 'extension'
keyword ::= 'import'
keyword ::= 'func'
keyword ::= 'metatype'
keyword ::= 'union'
keyword ::= 'protocol'
keyword ::= 'static'
keyword ::= 'struct'
keyword ::= 'subscript'
keyword ::= 'typealias'
keyword ::= 'var'
keyword ::= 'where'
// Statements
keyword ::= 'break'
keyword ::= 'case'
keyword ::= 'continue'
keyword ::= 'default'
keyword ::= 'do'
keyword ::= 'else'
keyword ::= 'if'
keyword ::= 'in'
keyword ::= 'for'
keyword ::= 'return'
keyword ::= 'switch'
keyword ::= 'then'
keyword ::= 'while'
// Expressions
keyword ::= 'as'
keyword ::= 'is'
keyword ::= 'new'
keyword ::= 'super'
keyword ::= 'self'
keyword ::= 'Self'
keyword ::= '__COLUMN__'
keyword ::= '__FILE__'
keyword ::= '__LINE__'
</pre>
<p>These are the builtin keywords.</p>
<!-- ===================================================================== -->
<h3 id="integer_literal">Integer Literals</h3>
<!-- ===================================================================== -->
<pre class="grammar">
integer_literal ::= [0-9][0-9_]*
integer_literal ::= 0x[0-9a-fA-F][0-9a-fA-F_]*
integer_literal ::= 0o[0-7][0-7_]*
integer_literal ::= 0b[01][01_]*
</pre>
<p>Integer literal tokens represent simple integer values of unspecified
precision. They may be expressed in decimal, binary with the '<tt>0b</tt>'
prefix, octal with the '<tt>0o</tt>' prefix, or hexadecimal with the
'<tt>0x</tt>' prefix. Unlike C, a leading zero does not affect the base
of the literal.
<p>Integer literals may contain underscores at arbitrary positions after
the first digit. These underscores may be used for human readability
and do not affect the value of the literal.</p>
<pre class="example">
789
0789
1000000
1_000_000
0b111_101_101
0o755
0b1111_1011
0xFB
</pre>
<!-- ===================================================================== -->
<h3 id="floating_literal">Floating Point Literals</h3>
<!-- ===================================================================== -->
<div class="commentary">
We require a digit on both sides of the dot to allow lexing "4.km" as
"4 . km" instead of "4. km" and for a series of dots to be an operator (for
ranges). The regex for decimal literals is same as Java, and the one for
hex literals is the same as C99, except that we do not allow a trailing
suffix that specifies a precision.
</div>
<pre class="grammar">
floating_literal ::= [0-9][0-9_]*\.[0-9][0-9_]*
floating_literal ::= [0-9][0-9_]*\.[0-9][0-9_]*[eE][+-]?[0-9][0-9_]*
floating_literal ::= [0-9][0-9_]*[eE][+-]?[0-9][0-9_]*
floating_literal ::= 0x[0-9A-Fa-f][0-9A-Fa-f_]*
(\.[0-9A-Fa-f][0-9A-Fa-f_]*)?[pP][+-]?[0-9][0-9_]*
</pre>
<p>Floating point literal tokens represent floating point values of
unspecified precision. Decimal and hexadecimal floating-point literals are
supported.
<p>The integer, fraction, and exponent of a floating point literal may each
contain underscores at arbitrary positions after their first digits. These
underscores may be used for human readability and do not affect the value
of the literal. Each part of the floating point literal must however start
with a digit; <tt>1._0</tt> would be a reference to the <tt>_0</tt> member
of <tt>1</tt>.
<pre class="example">
1.0
1000000.75
1_000_000.75
0x1.FFFFFFFFFFFFFp1022
0x1.FFFF_FFFF_FFFF_Fp1_022
</pre>
<!-- ===================================================================== -->
<h3 id="character_literal">Character Literals</h3>
<!-- ===================================================================== -->
<pre class="grammar">
character_literal ::= '[^'\\\n\r]|character_escape'
character_escape ::= [\]0 [\][\] | [\]t | [\]n | [\]r | [\]" | [\]'
character_escape ::= [\]x hex hex
character_escape ::= [\]u hex hex hex hex
character_escape ::= [\]U hex hex hex hex hex hex hex hex
hex ::= [0-9a-fA-F]
</pre>
<p>character_literal tokens represent a single character, and are surrounded
by single quotes.</p>
<p>The ASCII and Unicode character escapes:</p>
<pre>
\0 == nul
\n == new line
\r == carriage return
\t == horizontal tab
\u == small Unicode code points
\U == large Unicode code points
\x == raw ASCII byte (less than 0x80)
</pre>
<!-- ===================================================================== -->
<h3 id="string_literal">String Literals</h3>
<!-- ===================================================================== -->
<div class="commentary">
FIXME: Forcing + to concatenate strings is somewhat gross, a proper protocol
would be better.
</div>
<pre class="grammar">
string_literal ::= ["]([^"\\\n\r]|character_escape|escape_expr)*["]
escape_expr ::= [\]escape_expr_body
escape_expr_body ::= [(]escape_expr_body[)]
escape_expr_body ::= [^\n\r"()]
</pre>
<p>string_literal tokens represent a string, and are surrounded by double
quotes. String literals cannot span multiple lines.</p>
<p>String literals may contain embedded expressions in them (known as
"interpolated expressions") subject to some specific lexical constraints:
the expression may not contain a double quote ["], newline [\n], or carriage
return [\r]. All parentheses must be balanced.</p>
<p>In addition to these lexical rules, an interpolated expression must satisfy
the <a href="#expr">expr</a> production of the general swift grammar. This
expression is evaluated, and passed to the constructor for the inferred type
of the string literal. It is concatenated onto any fixed portions of the
string literal with a global "+" operator that is found through normal name
lookup.</p>
<pre class="example">
// Simple string literal.
"Hello world!"
// Interpolated expressions.
"\(min)..\(max)" + "Result is \((4+i)*j)"
</pre>
<!-- ===================================================================== -->
<h3 id="identifier">Identifier Tokens</h3>
<!-- ===================================================================== -->
<div>
<pre class="grammar">
identifier ::= id-start id-continue*
// An identifier can start with an ASCII letter or underscore...
id-start ::= [A-Za-z_]
// or a Unicode alphanumeric character in the Basic Multilingual Plane...
// (excluding combining characters, which can't appear initially)
id-start ::= [\u00A8\u00AA\u00AD\u00AF\u00B2-\u00B5\u00B7-00BA]
id-start ::= [\u00BC-\u00BE\u00C0-\u00D6\u00D8-\u00F6\u00F8-\u00FF]
id-start ::= [\u0100-\u02FF\u0370-\u167F\u1681-\u180D\u180F-\u1DBF]
id-start ::= [\u1E00-\u1FFF]
id-start ::= [\u200B-\u200D\u202A-\u202E\u203F-\u2040\u2054\u2060-\u206F]
id-start ::= [\u2070-\u20CF\u2100-\u218F\u2460-\u24FF\u2776-\u2793]
id-start ::= [\u2C00-\u2DFF\u2E80-\u2FFF]
id-start ::= [\u3004-\u3007\u3021-\u302F\u3031-\u303F\u3040-\uD7FF]
id-start ::= [\uF900-\uFD3D\uFD40-\uFDCF\uFDF0-\uFE1F\uFE30-FE44]
id-start ::= [\uFE47-\uFFFD]
// or a non-private-use, valid code point outside of the BMP.
id-start ::= [\u10000-\u1FFFD\u20000-\u2FFFD\u30000-\u3FFFD\u40000-\u4FFFD]
id-start ::= [\u50000-\u5FFFD\u60000-\u6FFFD\u70000-\u7FFFD\u80000-\u8FFFD]
id-start ::= [\u90000-\u9FFFD\uA0000-\uAFFFD\uB0000-\uBFFFD\uC0000-\uCFFFD]
id-start ::= [\uD0000-\uDFFFD\uE0000-\uEFFFD]
// After the first code point, an identifier can contain ASCII digits...
id-continue ::= [0-9]
// and/or combining characters...
id-continue ::= [\u0300-\u036F\u1DC0-\u1DFF\u20D0-\u20FF\uFE20-\uFE2F]
// in addition to the starting character set.
id-continue ::= id-start
</pre>
<p>The set of valid identifier characters is consistent with WG14 N1518,
"Recommendations for extended identifier characters for C and C++".
This roughly corresponds to the alphanumeric characters in the Basic
Multilingual Plane and all non-private-use code points outside of the BMP.
It excludes mathematical symbols, arrows, line and
box drawing characters, and private-use and invalid code points.
An identifier cannot begin with one of the ASCII digits '0' through '9'
or with a combining character.</p>
<p>The Swift compiler does not normalize Unicode source code, and matches
identifiers by code points only. Source code must be normalized to a
consistent normalization form before being submitted to the compiler.
<pre class=example>
// Valid identifiers
foo
_0
swift
vernissé
&#x95EA;&#x4EAE;
&#x05de;&#x05d1;&#x05e8;&#x05d9;&#x05e7;
&#x1F604;
// Invalid identifiers
&#x2603; // Is a symbol
0cool // Starts with an ASCII digit
&#x0301;foo // Starts with a combining character
&#xF8FF; // Is a private-use character
</pre>
<h4>Operators</h4>
<div class="commentary">
<br><br><b>[1]</b> The '=' token is explicitly handled in the grammar elsewhere,
and in general users cannot provide custom definitions for the '=' operator.
This distinctly differs from C++, which allows '=' to be overloaded.
<br><br><b>[2]</b> The '-&gt;' token is <a href="#reserved_punctuation">reserved punctuation</a>,
and cannot be used as an operator identifier.
<br><br><b>[3]</b> The unary prefix '&amp;' token is <a href="#reserved_punctuation">reserved punctuation</a>,
and cannot be used as an operator identifier.
<br><br><b>[4]</b> The '//', '/*', and '*/' tokens are <a href="#whitespace">reserved for comments</a>,
and cannot be used as operator identifiers.
</div>
<pre class="grammar">
<a name="operator">operator</a> ::= [@/=-+*%&lt;&gt;!&amp;|^~]+
<a name="operator">operator</a> ::= \.\.
Note: excludes '=', see <b>[1]</b>
excludes '-&gt;', see <b>[2]</b>
excludes unary '&amp;', see <b>[3]</b>
excludes '//', '/*', and '*/', see <b>[4]</b>
'..' is an operator, not two '.'s.
operator-binary ::= operator
operator-prefix ::= operator
operator-postfix ::= operator
left-binder ::= [ \r\n\t\(\[\{,;:]
right-binder ::= [ \r\n\t\)\]\},;:]
<a name="any-identifier">any-identifier</a> ::= identifier | operator
</pre>
<p><tt>operator-binary</tt>, <tt>operator-prefix</tt>, and
<tt>operator-postfix</tt> are distinguished by immediate lexical
context. An operator token is called <i>left-bound</i> if it
is immediately preceded by a character matching <tt>left-binder</tt>.
An operator token is called <i>right-bound</i> if it is immediately
followed by a character matching <tt>right-binder</tt>. An operator
token is an <tt>operator-prefix</tt> if it is right-bound but not
left-bound, an <tt>operator-postfix</tt> if it is left-bound but
not right-bound, and an <tt>operator-binary</tt> in either of the
other two cases.
</p>
<p>As an exception to the above rule, an operator immediately followed by a
dot ('.') is only considered right-bound if not already left-bound. This
allows <code>a@.prop</code> to be parsed as <code>(a@).prop</code> rather
than as <code>a @ .prop</code>. Similarly, because the '!' operator is
defined by the standard library to destructure
<a href="#type-optional">optional types</a> and is thus expected to be used
ubiquitously, it is also only considered right-bound if not already
left-bound.</p>
<p>When parsing certain grammatical constructs that involve '&lt;' and
'&gt;' (such as <a href="#type-composition">protocol composition
types</a>), an <tt>operator</tt> with a leading '&lt;' or '&gt;' may
be split into two or more tokens: the leading '&lt;' or '&gt;' and
the remainder of the token, which may be an <tt>operator</tt> or
<tt>punctuation</tt> token that may itself be further split. This
rule allows us to parse nested constructs such as
<code>A&lt;B&lt;C&gt;&gt;</code> without requiring spaces between
the closing '&gt;'s.</p>
</div>
<!-- ===================================================================== -->
<h3 id="dollarident">Implementation Identifier Token</h3>
<!-- ===================================================================== -->
<pre class="grammar">
dollarident ::= '$' id-continue+
</pre>
<p>Tokens that start with a $ are separate class of identifier, which are
fixed purpose names that are defined by the implementation.
</p>
<!-- ********************************************************************* -->
<h2 id="decl">Declarations</h2>
<!-- ********************************************************************* -->
<pre class="grammar">
decl ::= <a href="#decl-class">decl-class</a>
decl ::= <a href="#decl-constructor">decl-constructor</a>
decl ::= <a href="#decl-destructor">decl-destructor</a>
decl ::= <a href="#decl-extension">decl-extension</a>
decl ::= <a href="#decl-func">decl-func</a>
decl ::= <a href="#decl-import">decl-import</a>
decl ::= <a href="#decl-union">decl-union</a>
decl ::= <a href="#decl-union-element">decl-union-element</a>
decl ::= <a href="#decl-protocol">decl-protocol</a>
decl ::= <a href="#decl-struct">decl-struct</a>
decl ::= <a href="#decl-typealias">decl-typealias</a>
decl ::= <a href="#decl-var">decl-var</a>
decl ::= <a href="#decl-subscript">decl-subscript</a>
</pre>
<!-- ===================================================================== -->
<h3 id="decl-translation-unit">Translation Unit</h3>
<!-- ===================================================================== -->
<pre class="grammar">
translation-unit ::= <a href="#brace-item-list">brace-item</a>*
</pre>
<p>The top level of a swift source file is grammatically identical to the
contents of a func decl. Some declarations
have semantic restrictions that only allow them within a translation unit
though.
</p>
<!-- _____________________________________________________________________ -->
<h4 id="brace-item-list">Brace Enclosed Items</h4>
<pre class="grammar">
brace-item-list ::= '{' brace-item* '}'
brace-item ::= <a href="#decl">decl</a>
brace-item ::= <a href="#expr">expr</a>
brace-item ::= <a href="#stmt">stmt</a>
</pre>
<p>The brace item list provides a sequencing operation which evaluates the
members of its body in order. Function bodies and the bodies of control
flow statements use braces. Also, the <a
href="#decl-translation-unit">translation unit</a> itself is effectively a
brace item list, but without the braces.
</p>
<!-- ===================================================================== -->
<h3 id="decl-import">import Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-import ::= 'import' <a href="#attribute-list">attribute-list</a> import-kind? import-path
import-kind ::= 'typealias'
import-kind ::= 'struct'
import-kind ::= 'class'
import-kind ::= 'union'
import-kind ::= 'protocol'
import-kind ::= 'var'
import-kind ::= 'func'
import-path ::= <a href="#any-identifier">any-identifier</a> ('.' <a href="#any-identifier">any-identifier</a>)*
</pre>
<p>'import' declarations allow named values and types to be accessed with
local names, even when they are defined in other modules and namespaces. See
the section on <a href="#namebind">name binding</a> for more
information on how these work. import declarations are only allowed at
translation unit scope.</p>
<p>'import' directives only impact a single translation unit: imports in one
swift file do not affect name lookup in another file. import directives can
only occur at the top level of a file, not within a function or namespace.</p>
<p>An import without an explicit import-kind names a module; all of the
module's members are imported into the current scope. The module's name is
also imported into the the current scope in order to allow qualified access
to the module's members, which can be useful for disambiguation.</p>
<p>If an import-kind is provided, the last element of the import path is
taken to be the name of a decl <em>within</em> the module named by the rest of
the path. Only that name is introduced into the current scope; the name of the
module itself is <em>not</em> accessible, nor any other decls within the
module.</p>
<p>Different import-kinds perform different filters on the decls within a
module:</p>
<ul>
<li><code>typealias</code> can be used to import any concrete type (struct,
class, union, or another typealias). It cannot be used to import protocols,
which are often used for more than just their existential type.</li>
<li><code>struct</code>, <code>class</code>, <code>union</code> can be used
to import any type whose <i>canonical type</i> is a struct, class,
or union, respectively. (This allows "Int" to be imported as a struct, for
example, even though its definition in the standard library may be a
typealias for another struct type.)</li>
<li><code>protocol</code> is used to import a protocol</li>
<li><code>var</code> is used to import a module-scoped variable</li>
<li><code>func</code> will import all overloads of a function</li>
</ul>
<pre class="example">
<i>// Import all of the top level symbols and types in a module.</i>
import swift
<i>// Import all of the symbols within a submodule.</i>
import swift.io
<i>// Import a single variable, function, type, etc.</i>
import typealias swift.io.BufferedStream
<i>// Import all addition overloads.</i>
import func swift.+
</pre>
<!-- ===================================================================== -->
<h3 id="decl-extension">extension Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-extension ::= 'extension' <a href="#type-identifier">type-identifier</a> <a href="#inheritance">inheritance</a>? '{' <a href="#decl">decl</a>* '}'
</pre>
<p>'extension' declarations allow adding member declarations to existing
types, even in other translation units and modules. There are different
semantic rules for each type that is extended.
</p>
<!-- _____________________________________________________________________ -->
<h4 id="decl-extension-union-struct"><a href="#decl-union">union</a>, <a
href="#decl-struct">struct</a>, and <a href="#decl-class">class</a>
declaration extensions</h4>
<p>FIXME: Write this section.</p>
<!-- ===================================================================== -->
<h3 id="decl-var">var Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-var ::= 'var' <a href="#attribute-list">attribute-list</a> <a href="#pattern">pattern</a> initializer? (',' pattern initializer?)*
decl-var ::= 'var' <a href="#attribute-list">attribute-list</a> <a href="#identifier">identifier</a> ':' <a href="#type">type-annotation</a> <a href="#brace-item-list">brace-item-list</a>
decl-var ::= 'var' <a href="#attribute-list">attribute-list</a> <a href="#identifier">identifier</a> ':' <a href="#type">type-annotation</a> '{' get-set '}'
initializer ::= '=' <a href="#expr">expr</a>
<a name="get-set"></a>get-set ::= get set?
get-set ::= set get
get ::= 'get:' <a href="#brace-item-list">brace-item*</a>
set ::= 'set' set-name? ':' <a href="#brace-item-list">brace-item*</a>
set-name ::= '(' <a href="#identifier">identifier</a> ')'
</pre>
<p>'var' declarations form the backbone of value declarations in Swift. A var
declaration takes a pattern and an optional initializer, and declares all the
pattern-identifiers in the pattern as variables. If there is an initializer
and the pattern is <a href="#fully_typed_types">fully-typed</a>, the
initializer is converted to the type of the pattern. If there is an
initializer and the pattern is not fully-typed, the type of initializer is
computed independently of the pattern, and the type of the pattern is derived
from the initializer. If no initializer is specified, the pattern must be
fully-typed, and the values are default-initialized.</p>
<p>If there is more than one pattern in a 'var' declaration, they are each
considered independently, as if there were multiple declarations. The
initial attribute-list is shared between all the declared variables.
<p>A var declaration may contain a getter and (optionally) a setter,
which will be used when reading or writing the variable, respectively.
Such a variable does not have any associated storage. A var
declaration with a getter or setter must have a type (call it
<code>T</code>). The getter function, whose body is provided as part
of the <code>var-get</code> clause, has type <code>() -> T</code>.
Similarly, the setter function, whose body is part of the
<code>var-set</code> clause (if provided), has type <code>(T)
-> ()</code>. If the <code>var-set</code> clause contains a <code>var-set-name</code>
clause, the identifier of that clause is used as the name of the
parameter to the setter. Otherwise, the parameter name is "value".</p>
<p>FIXME: Should the type of a pattern which isn't fully typed affect the
type-checking of the expression (i.e. should we compute a structured
dependent type)?</p>
<p>Like all other declarations, var's can optionally have a list of <a
href="#attribute-list">attributes</a> applied to them.</p>
<p>The type of a variable must be
<a href="#materializable"><i>materializable</i></a>. A variable is
an lvalue unless it has a <code>var-get</code> clause but not
<code>var-set</code> clause. </p>
<p>Here are some examples of var declarations:</p>
<pre class="example">
<i>// Simple examples.</i>
var a = 4
var b : Int
var c : Int = 42
<i>// This decodes the tuple return value into independently named parts</i>
<i>// and both 'val' and 'err' are in scope after this line.</i>
var (val, err) = foo()
<i>// Variable getter/setter</i>
var _x : Int = 0
var x_modify_count : Int = 0
var x1 : Int {
return _x
}
var x2 : Int {
get:
return _x
set:
x_modify_count = x_modify_count + 1
_x = value
}
</pre>
<p>Note that both 'get' and 'set' are context-sensitive keywords.</p>
<!-- ===================================================================== -->
<h3 id="decl-func">func Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-func ::= 'static'? 'func' <a href="#attribute-list">attribute-list</a> <a href="#any-identifier">any-identifier</a> <a href="#func-signature">func-signature</a> <a href="#brace-item-list">brace-item-list</a>?
</pre>
<p>'func' is a declaration for a function. The argument list and
optional return value are specified by the type production of the function,
and the body is either a brace expression or elided. Like all other
declarations, functions are can have attributes.</p>
<p>If the type is not syntactically a function type (i.e., has no -&gt; in it
at top-level), then the return value is implicitly inferred to be
"<tt>()</tt>". All of the argument and return value names are injected into
the <a href="#namebind_scope">scope</a> of the function body.</p>
<p>A function in an <a href="#decl-extension">extension</a> of some type (or
in other places that are semantically equivalent to an extension) implicitly
get a 'self' argument with these rules ... [todo]</p>
<p>'static' functions are only allowed in an <a
href="#decl-extension">extension</a> of some type (or in other places
that are semantically equivalent to an extension). They indicate that
the function is actually defined on the <a href="#metatype">metatype</a>
for the type, not on the
type itself. Thus it does not implicitly get a first 'self' argument, and
can be used with dot syntax on the metatype.</p>
<p>TODO: Func should be an immutable name binding, it should implicitly add
an attribute immutable when it exists.</p>
<p>TODO: Incoming arguments should be readonly, result should be implicitly
writeonly when we have these attributes.</p>
<!-- _____________________________________________________________________ -->
<h4 id="func-signature">Function signatures</h4>
<pre class="grammar">
func-signature ::= func-arguments func-signature-result?
func-arguments ::= <a href="#pattern-tuple">pattern-tuple</a>+
func-arguments ::= selector-tuple
selector-tuple ::= '(' <a href="#pattern-tuple">pattern-tuple-element</a> ')' (<a href="#identifier">identifier</a> '(' pattern-tuple-element ')')+
func-signature-result ::= '-&gt;' <a href="#type">type</a>
</pre>
<p>A function signature specifies one or more sets of parameter
patterns, plus an optional result type.</p>
<p>When a result type is not written, it is implicitly the empty tuple type,
<tt>()</tt>.</p>
<p>In the body of the function described by a particular signature,
all the variables bound by all of the parameter patterns are in
scope, and the function must return a value of the result type.</p>
<p>An outermost pattern in a function signature must be <a
href="#fully_typed_types">fully-typed</a> and irrefutable. If a result type is
given, it must also be fully-typed.</p>
<p>The type of a function with signature <tt>(P<sub>0</sub>)(P<sub>1</sub>)..(P<sub><i>n</i></sub>) -&gt; R</tt>
is <tt>T<sub>0</sub> -&gt; T<sub>1</sub> -&gt; .. -&gt; T<sub><i>n</i></sub> -&gt; R</tt>,
where <tt>T<sub><i>i</i></sub></tt> is the bottom-up type of the pattern
<tt>P<sub><i>i</i></sub></tt>. This is called "currying". The
behavior of all the intermediate functions (those which do not
return <tt>R</tt>) is to capture their arguments, plus any
arguments from prior patterns, and returns a function which takes
the next set of arguments. When the "uncurried" function is
called (the one taking <tt>T<sub><i>n</i></sub></tt> and returning
<tt>R</tt>), all of the arguments are then available and the
function body is finally evaluated as normal.</p>
<p>A function declared with a selector-style signature
<tt>func(a<sub>0</sub>:T<sub>0</sub>) name<sub>1</sub>(a<sub>1</sub>:T<sub>1</sub>) .. name<sub><i>n</i></sub>(a<sub><i>n</i></sub>:T<sub><i>n</i></sub>) -&gt; R</tt>
has the type <tt>(_:T<sub>0</sub>, name<sub>1</sub>:T<sub>1</sub>, .. name<sub><i>n</i></sub>:T<sub><i>n</i></sub>) -&gt; R</tt>,
that is, the names of the fields in the argument tuple are the
<tt>name<sub><i>n</i></sub></tt> identifiers preceding each argument
pattern. However, in the body of a function
described by a signature, those arguments will be bound using the
corresponding
<tt>a<sub><i>n</i></sub></tt> patterns inside
the arguments. This allows for Cocoa-style keyword function
names such as <tt>doThing(x, withThing:y)</tt> to be defined without
requiring that an awkward keyword name be the same as the
variable name.
<p>Here are some examples of func definitions:</p>
<pre class="example">
<i>// Implicitly returns (), aka <a href="#stdlib-Void">Void</a></i>
func a() {}
<i>// Same as 'a'</i>
func a1() -&gt; Void {}
<i>// Function pointers to a function expression.</i>
var a2 = func ()-&gt;() {}
var a3 = func () {}
var a4 = func {}
<i>// Really simple function</i>
func c(arg : Int) -&gt; Int { return arg+4 }
<i>// Simple operators.</i>
func [infix_left=190] + (lhs : Int, rhs : Int) -&gt; Int
func [infix_left=160] == (lhs : Int, rhs : Int) -&gt; Bool
<i>// Curried function with multiple return values:</i>
func d(a : Int) (b : Int) -&gt; (res1 : Int, res2 : Int) {
return (a,b)
}
<i>// A more realistic example on a trivial type.</i>
struct bankaccount {
amount : Int
static func bankaccount() -> bankaccount {
// Custom 'constructor' logic goes here.
}
func deposit(arg : Int) {
amount = amount + arg
}
static func someMetaTypeMethod() {}
}
<i>// Dot syntax on metatype.</i>
bankaccount.someMetaTypeMethod()
<i>// A function with selector-style signature.</i>
union PersonOfInterest {
case ColonelMustard
case MissScarlet
}
union Room {
case Conservatory
case Ballroom
}
union Weapon {
case Candlestick
case LeadPipe
}
func accuseSuspect(suspect:PersonOfInterest)
inRoom(room:Room)
withWeapon(weapon:Weapon) {
println("It was \(suspect) in the \(room) with the \(weapon)")
}
<i>// Calling a selector-style function.</i>
accuseSuspect(.ColonelMustard, inRoom:.Ballroom, withWeapon:.LeadPipe)
</pre>
<!-- ===================================================================== -->
<h3 id="decl-typealias">typealias Declarations</h3>
<!-- ===================================================================== -->
<div class="commentary">
We use the keyword "typealias" instead of "typedef" because it really is an
alias for an existing type, not a "definition" of a new type.
</div>
<pre class="grammar">
decl-typealias ::= typealias-head '=' <a href="#type">type</a>
<a name="typealias-head"></a>typealias-head ::= 'typealias' <a href="#identifier">identifier</a> <a href="#inheritance">inheritance</a>?
</pre>
<p>'typealias' makes a named alias of a type, like a typedef in C. From that
point on, the alias may be used in all situations the specified name is. If an <a href="#inheritance">inheritance</a> clause is provided, it specifies protocols to which the aliased type shall conform.</p>
<p>Here are some examples of type aliases:</p>
<pre class="example">
<i>// location is an alias for a tuple of ints.</i>
typealias location = (x : Int, y : Int)
<i>// pair_fn is a function that takes two ints and returns a tuple.</i>
typealias pair_fn = (Int) -&gt; (Int) -&gt; (first : Int, second : Int)
</pre>
<!-- ===================================================================== -->
<h3 id="decl-union">union Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-union ::= 'union' <a href="#attribute-list">attribute-list</a> <a href="#identifier">identifier</a> <a href="#inheritance">inheritance</a>? union-body
union-body ::= '{' decl* '}'
decl-union-element ::= 'case' union-case (',' union-case)*
union-case ::= <a href="#identifier">identifier</a> <a href="#type-tuple">type-tuple</a>? ('->' <a href="#type">type</a>)?
</pre>
<p>A union declaration creates a <a href="#type-union">union type</a>.
Here are some examples of union declarations:</p>
<pre class="example">
<i>// Declare discriminated union with union decl.</i>
union SomeInts {
case None
case One(Int)
case Two(Int, Int)
}
<i>// Declares three "enums".</i>
union DataSearchFlags {
case None
case Backward
case Anchored
}
func f1(searchpolicy : DataSearchFlags) <i>// DataSearchFlags is a valid type name</i>
func test1() {
f1(DataSearchFlags.None) <i>// Use of constructor with qualified identifier</i>
f1(.None) <i>// Use of constructor with context sensitive type inference</i>
<i>// "None" has no type argument, so the constructor's type is "DataSearchFlags".</i>
var a : DataSearchFlags = .None
}
union SomeMoreInts {
case None <i>// Doesn't conflict with previous "None".</i>
case One(Int)
case Two(Int, Int)
}
func f2(a : SomeMoreInts)
func test2() {
<i>// Constructors for union element can be used in the obvious way.</i>
f2(.None)
f2(.One(4))
f2(.Two(1, 2))
<i>// Constructor for None has type "SomeMoreInts".</i>
var a : SomeMoreInts = SomeMoreInts.None
<i>// Constructor for One has type "(Int) -&gt; SomeMoreInts".</i>
var b : (Int) -&gt; SomeMoreInts = SomeMoreInts.One
<i>// Constructor for Two has type "(Int,Int) -&gt; SomeMoreInts".</i>
var c : (Int,Int) -&gt; SomeMoreInts = SomeMoreInts.Two
}
</pre>
<!-- ===================================================================== -->
<h3 id="decl-struct">struct Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-struct ::= 'struct' <a href="#attribute-list">attribute-list</a> <a href="#identifier">identifier</a> <a href="#inheritance">inheritance</a>? '{' decl-struct-body '}'
decl-struct-body ::= <a href="#decl">decl</a>*
</pre>
<p>A struct declares a simple value type that can contain data members and
have methods.</p>
<p>The body of a 'struct' is a list of decls. Non-property 'var' decls
declare members with storage in the struct. Other declarations act like
they would in an <a href="#decl-extension">extension</a> of the
struct type.</p>
<p>Here are a few simple examples:</p>
<pre class="example">
struct S1 {
var a : Int, b : Int
}
struct S2 {
var a : Int
func f() -> Int { return b }
var b : Int
}
</pre>
<p>Here are some more realistic examples of structs:</p>
<pre class="example">
struct Point { x : Int, y : Int }
struct Size { width : Int, height : Int }
struct Rect {
origin : Point,
size : Size
typealias CoordinateType = Int
func area() -> Int { return size.width*size.height }
}
func test4() {
var a : Point
var b = Point.Point(1, 2) // Silly but fine.
var c = Point(y = 1, x = 2) // Using metatype.
var x1 = Rect(a, Size(42, 123))
var x2 = Rect(size = Size(width = 42, height=123), origin = a)
var x1_area = x1.width*x1.height
var x1_area2 = x1.area()
}
</pre>
<!-- ===================================================================== -->
<h3 id="decl-class">class Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-class ::= 'class' <a href="#attribute-list">attribute-list</a> <a href="#identifier">identifier</a> <a href="#inheritance">inheritance</a>? '{' decl-class-body '}'
decl-class-body ::= <a href="#decl">decl</a>*
</pre>
<p>A class declares a reference type referring to an object which can contain
data members and have methods. Classes support single inheritance;
a parent class should be listed as the first type in the
inheritance list.</p>
<p>The body of a 'class' is a list of decls. Non-property 'var' decls
declare members with storage in the class. Non-static 'var' and 'func'
decls declare instance members; static 'var' and 'func' decls declare
members of the class itself. Both class and instance members can
be overridden by a subclass.</p>
<p>Type declarations inside a class act essentially the same way as type
declarations outside a class.</p>
<p>FIXME: For the moment, see classes.rst for more details on the
class system.</p>
<p>FIXME: Add a reference to the section on generics.</p>
<p>The only way to create a new instance of a class is with a
<a href="#expr-new">new expression</a>.
<p>Here is a simple example:</p>
<pre class="example">
class C1 {
var a : Int
var b : Int
}
</pre>
<!-- ===================================================================== -->
<h3 id="decl-protocol">Protocol Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-protocol ::= 'protocol' <a href="#attribute-list">attribute-list</a> <a href="#identifier">identifier</a> <a href="#inheritance">inheritance</a>? '{' protocol-member* '}'
</pre>
<p>A protocol declaration describes an abstract interface implemented by
another type. It consists of a set of declarations, which may be instance
methods or properties. A type <i>conforms</i> to a protocol if it
provides declarations that correspond to each of the declarations in
a protocol.</p>
<p>Here are some examples of protocols:</p>
<pre class="example">
protocol Document {
var title : String
}
</pre>
<!-- _____________________________________________________________________ -->
<h4 id="protocol-member-func">'func' protocol elements</h4>
<pre class="grammar">
protocol-member ::= <a href="#decl-func">decl-func</a>
</pre>
<p>'func' members of a protocol define a value of function type that may be
accessed with dot syntax on a value of the protocol's type. The function
gets an implicit "self" argument of the protocol type and shall not
be static.</p>
<!-- _____________________________________________________________________ -->
<h4 id="protocol-member-var">'var' protocol elements</h4>
<pre class="grammar">
protocol-member ::= <a href="#decl-var">decl-var</a>
</pre>
<p>'var' members of a protocol define "property" values that may be accessed
with dot syntax on a value of the protocol's type. The actual
variables have no storage, and will instead by accessed by a getter
and setter. Thus, the variables shall have neither an initializer
nor a getter/setter clause.</p>
<!-- _____________________________________________________________________ -->
<h4 id="protocol-member-subscript">'subscript' protocol elements</h4>
<pre class="grammar">
protocol-member ::= <a href="#subscript-head">subscript-head</a>
</pre>
<p>'subscript' members of a protocol define subscripting operations
that may be accessed with the subscript operator ('[]') applied to a
value of the protocol's type. </p>
<div class="commentary">
TODO: There is currently no way to express a requirement for a
read-only or write-only subscript operation or variable. We may
end up doing this with some kind of 'const' or 'immutable'
attribute.
</div>
<!-- _____________________________________________________________________ -->
<h4 id="protocol-member-typealias">'typealias' protocol elements (associated types)</h4>
<pre class="grammar">
protocol-member ::= <a href="#typealias-head">typealias-head</a>
</pre>
<p>'typealias' members of a protocol define associated types, which
are types used within the description of a protocol (typically in
the inputs and outputs of 'func' members) that vary from one
conforming type to another. When an associated type has an <a
href="#inheritance">inheritance</a> clause, any type meant to
satisfy the associated type requirement must conform to each of the
protocols specified within that inheritance clause.</p>
<pre class="example">
protocol Enumerable {
typename EnumeratorType : Enumerator
func getElements() -> EnumeratorType
}
</pre>
<!-- ===================================================================== -->
<h3 id="decl-subscript">subscript Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-subscript ::= subscript-head '{' <a href="#get-set">get-set<a/> '}'
<a id="subscript-head"></a>subscript-head ::= 'subscript' <a href="#attribute-list">attribute-list</a> <a href="#pattern-tuple">pattern-tuple</a> '->' <a href="#type">type</a>
</pre>
<p>A subscript declaration provides support for <a
href="#expr-subscript"> subscripting</a> an object of a particular
type via a getter and (optional) setter. Therefore, subscript
declarations can only appear within a type definition or
extension.</p>
<p> The <tt>pattern-tuple</tt> of a subscript declaration provides
the indices that will be used in the subscript expression, e.g., the
<tt>i</tt> in <tt>a[i]</tt>. This pattern must be fully-typed. The
<tt>type</tt> following the arrow provides the type of element being
accessed, which must be materializable. Subscript declarations can be
overloaded, so long as either the <tt>pattern-tuple</tt> or
<tt>type</tt> differs from other declarations.</p>
<p>The <tt>get-set</tt> clause specifies the getter and setter used
for subscripting. The getter is a function whose input is the type of
the <tt>pattern-tuple</tt> and whose result is the element type.
Similarly, the setter is a function whose result type is <tt>()</tt>
and whose input is the type of the <tt>pattern-tuple</tt> with a
parameter of the element type added to the end of the tuple; the name
of the parameter is the <tt>set-name</tt>, if provided, or
<tt>value</tt> otherwise.
<pre class="example">
<i>// Simple bit vector with storage for 64 boolean values</i>
struct BitVector64 {
bits : Int64
<i>// Allow subscripting with integer subscripts and a boolean result.</i>
subscript (bit : Int) -&gt; Bool {
<i>// Getter tests the given bit</i>
get {
if (bits & (1 &lt;&lt; bit)) != 0 {
return true
}
return false;
}
<i>// Setter sets the given bit to the provided value</i>
set {
var mask = 1 &lt;&lt; bit
if value {
bits = bits | mask
} else {
bits = bits & ~mask
}
}
}
}
var vec : BitVector64
vec[2] = true
if vec[3] {
print("third bit is set\n");
}
</pre>
<!-- ===================================================================== -->
<h3 id="decl-constructor">constructor Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-constructor ::= 'constructor' <a href="#attribute-list">attribute-list</a> <a href="#pattern-tuple">pattern-tuple</a> <a href="#brace-item-list">brace-item-list</a>
</pre>
<p>'constructor' declares a constructor for a class, struct, or union. Such
a declaration is used whenever an object is constructed. Specifically,
for classes, it is used when a new expression is written, and for structs
and unions, it is used for function application when the "function"
is a metatype.</p>
<p>FIXME: We haven't decided the precise rules for when constructors are
implicitly declared. Default construction doesn't work right for structs
or unions. We haven't decided what the restrictions are if a member
isn't default-constructible.</p>
<p>A simple example:</p>
<pre class="example">
struct X {
var member : Int
constructor(x : Int) {
member = x
}
}
var a = X(10)
</pre>
<p>If a class is derived from a superclass, it must explicitly invoke a
superclass constructor using the <tt>super.constructor</tt> syntax.
<tt>super.constructor</tt> may only be used in a subclass constructor;
it is not valid in a struct, union, or root class constructor. Additionally,
<tt>super.constructor</tt> may only be referenced exactly once per derived
constructor. An example:</p>
<pre class="example">
class View {
var bounds : Rect
constructor(bounds:Rect) {
self.bounds = bounds
}
}
class Button : View {
var onClick : () -&gt; ()
constructor(bounds:Rect, onClick:() -&gt; ()) {
super.constructor(bounds)
self.onClick = onClick
}
}
</pre>
<!-- ===================================================================== -->
<h3 id="decl-destructor">destructor Declarations</h3>
<!-- ===================================================================== -->
<pre class="grammar">
decl-constructor ::= 'destructor' <a href="#attribute-list">attribute-list</a> <a href="#brace-item-list">brace-item-list</a>
</pre>
<p>'destructor' declares a destructor for a class. This function is called
when there are no longer any references to a class object, just before it
is destroyed. Note that destructors can only be declared for classes,
and cannot be declared in extensions. Subclass destructors implicitly
invoke their superclass destructors after executing.</p>
<p>FIXME: We haven't really decided the precise rules here, but it's probably
a fatal error to either throw an exception or stash a reference to 'self'
in a destructor. Not sure what happens when we cause the reference count
of another object to reach zero inside a destructor. We might eventually
allow destructors in extensions once we have ivars in extensions.</p>
<p>A simple example:</p>
<pre class="example">
class X {
var fd : Int
destructor {
close(fd)
}
}
</pre>
<!-- ===================================================================== -->
<h3 id="attribute-list">Attribute Lists</h3>
<!-- ===================================================================== -->
<pre class="grammar">
attribute-list ::= /*empty*/
attribute-list ::= attribute-list-clause attribute-list
attribute-list-clause ::= '[' ']'
attribute-list-clause ::= '[' attribute (',' attribute)* ']'
attribute ::= attribute-infix
attribute ::= attribute-resilience
attribute ::= attribute-byref
attribute ::= attribute-auto_closure
attribute ::= attribute-noreturn
</pre>
<p>An attribute list is written as a sequence of clauses delimited
by square brackets, each of which contains a (possibly empty)
comma-separated list of attributes. Neither the ordering of
attributes nor the grouping of attributes into separate clauses
has any semantic effect. Attributes may not be repeated within a
list.</p>
<!-- _____________________________________________________________________ -->
<h4 id="attribute-infix">Infix Attributes</h4>
<pre class="grammar">
attribute-infix ::= 'infix_left' '=' <a href="#integer_literal">integer_literal</a>
attribute-infix ::= 'infix_right' '=' <a href="#integer_literal">integer_literal</a>
attribute-infix ::= 'infix '=' <a href="#integer_literal">integer_literal</a>
</pre>
<p>The infix attributes may only be applied to the declaration of a
function of binary operator type whose name is an
<a href="#operator"><tt>operator</tt></a>. The name indicates the
associativity of the operator, either left associative, right associative, or
non-associative.</p>
<p>FIXME: Implement these restrictions.</p>
<!-- _____________________________________________________________________ -->
<h4 id="attribute-resilence">Resilience Attribute</h4>
<pre class="grammar">
attribute-resilience ::= 'resilient'
attribute-resilience ::= 'fragile'
attribute-resilience ::= 'born_fragile'
</pre>
<p>See the resilience design.</p>
<!-- _____________________________________________________________________ -->
<h4 id="attribute-byref">By-Reference Attribute</h4>
<pre class="grammar">
attribute-byref ::= 'byref'
</pre>
<p><tt>byref</tt> is only valid in a <tt>type-annotation</tt> that
appears within either a <a href="#pattern"><tt>pattern</tt></a> of
a <tt>function-signature</tt> or the input type of a function
type.
</p>
<p><tt>byref</tt> indicates that the argument will be passed "by
reference": the bound variable will be an l-value.</p>
<p>The type being annotated must be <a href="#materializable">materializable</a>.
The type after annotation is never materializable.</tt>
<p>FIXME: we probably need a const-like variant, which permits
r-values (and avoids writeback when the l-value is not physical).
We may also need some way of representing <q>this will be
consumed by the nth curry</q>.
</p>
<!-- _____________________________________________________________________ -->
<h4 id="attribute-auto_closure">auto_closure Attribute</h4>
<pre class="grammar">
attribute-auto_closure ::= 'auto_closure'
</pre>
<p>The <tt>auto_closure</tt> attribute modifies a <a
href="#type-function">function type</a>, changing the behavior of any
assignment into (or initialization of) a value with the function type.
Instead of requiring that the rvalue and lvalue have the same function type,
an "auto closing" function type requires its initializer expression to have
the same type as the function's result type, and it implicitly binds a
closure over this expression. This is typically useful for function arguments
that want to capture computation that can be run lazily.</p>
<p><tt>auto_closure</tt> is only valid in a <tt>type-annotation</tt> of a
syntactic function type that is defined to take a syntactic empty tuple.
</p>
<pre class="example">
<i>// An auto closure value. This captures an implicit closure over the</i>
<i>// specified expression, instead of the expression itself.</i>
var a : [auto_closure] () -&gt; Int = 4
<i>// Definition of an 'assert' function. Assertions and logging routines</i>
<i>// often want to conditionally evaluate their argument.</i>
func assert(condition : [auto_closure] () -> Bool)
<i>// Definition of the || operator - it captures its right hand side as</i>
<i>// an autoclosure so it can short-circuit evaluate it.</i>
func [infix_left=110] || (lhs: Bool, rhs: [auto_closure] ()->Bool) -&gt; Bool
<i>// Example uses of these functions:</i>
assert(i &lt; j)
if (a == 0 || b == 42) { ... }
</pre>
<!-- _____________________________________________________________________ -->
<h4 id="attribute-noreturn">No Return Attribute</h4>
<pre class="grammar">
attribute-noreturn ::= 'noreturn'
</pre>
<p>Attribute <tt>noreturn</tt> is only valid in the attribute list of a
function declaration or in the attribute list of a <tt>type-annotation</tt>
that describes a syntactic function type.
</p>
<p><tt>noreturn</tt> indicates to the compiler that the function will not
return to the caller. This attribute should be used to suppress the
uninitialized variable, missing return warnings and errors. The compiler is
also allowed to more aggressively optimize the code in presence of this
attribute.
</p>
<p>If a function with no a <tt>noreturn</tt> attribute contains a
<tt>return</tt> statement, an error will be raised.
</p>
<!-- ********************************************************************* -->
<h2 id="type">Types</h2>
<!-- ********************************************************************* -->
<pre class="grammar">
type ::= <a href="#type-function">type-function</a>
type ::= <a href="#type-array">type-array</a>
type-simple ::= <a href="#type-identifier">type-identifier</a>
type-simple ::= <a href="#type-tuple">type-tuple</a>
type-simple ::= <a href="#type-composition">type-composition</a>
type-simple ::= <a href="#type-metatype">type-metatype</a>
type-simple ::= <a href="#type-optional">type-optional</a>
type-annotation ::= <a href="#attribute-list">attribute-list</a> type
</pre>
<p>Swift has a small collection of core datatypes that are built into the
compiler. Most user-facing datatypes are defined by the
<a href="#stdlib">standard library</a> or declared as a user defined
types.</p>
<!-- _____________________________________________________________________ -->
<h3>Metatypes</h3>
<p id="metatype">Each type has a corresponding <i>metatype</i>, with the same
name as the type, that is injected into the standard name lookup scope when
a type is <a href="#decl">declared</a>. This allows access to '<a
href="#decl-func">static functions</a>' through dot syntax. For example:</p>
<pre class="example">
// Declares a type 'foo' as well as its metatype.
struct foo {
static func bar() {}
}
// Declares x to be of type foo. A reference to a name in type context
// refers to the type itself.
var x : foo
// Accesses a static function on the foo metatype. In a value context, the
// name of its type refers to its metatype.
foo.bar()
</pre>
<!-- _____________________________________________________________________ -->
<h3 id="fully_typed_types">Fully-Typed Types</h3>
<p>A type may be <i>fully-typed</i>. A type is fully-typed <i>unless</i> one
of the following conditions hold:</p>
<ol>
<li>It is a function type whose result or input type is not
fully-typed.</li>
<li>It is a tuple type with an element that is not
fully-typed. A tuple element is fully-typed unless it has no
explicit type (which is permitted for defaultable elements) or its
explicit type is not fully-typed. In other words, a type is
fully-typed unless it syntactically contains a tuple element with
no explicit type annotation.</li>
</ol>
<p>A type being 'fully-typed' informally means that the type is specified
directly from its type annotation without needing contextual or other
information to resolve its type.</p>
<!-- _____________________________________________________________________ -->
<h3>Materializable Types</h3>
<p id="materializable">A type may be <i>materializable</i>. A type
is materializable unless it is 1) annotated with
a <a href="#attribute-byref"><tt>byref</tt></a> attribute or 2) a
tuple with a non-materializable element type. In general, variables
must have materializable type.</p>
<!-- ===================================================================== -->
<h3 id="type-identifier">Named Types</h3>
<!-- ===================================================================== -->
<pre class="grammar">
type-identifier ::= type-identifier-component ('.' type-identifier-component)*
type-identifier-component ::= <a href="#identifier">identifier</a> generic-params?
generic-params ::= '&lt;' <a href="#type">type</a> (',' <a href="#type">type</a>)* '&gt;'
</pre>
<p>Named types may be used simply by using their name. Named types are
introduced by <a href="#decl-typealias">typealias</a> declarations or
through type declarations that expand to one.</p>
<pre class="example">
typealias location = (x : Int, y : Int)
var x : location <i>// use of a named type.</i>
</pre>
<p>Type names may use dot syntax to refer to names types declared in other
modules or types nested within other types.</p>
<pre class="example">
<i>// Direct reference to a member of another module.</i>
var x : swift.Int
</pre>
<p>Each component of a named type may be followed by a list of generic
parameters for that component enclosed in angle brackets <tt>&lt;&gt;</tt>.
<pre class="example">
<i>// A generic class definition.</i>
class Dict&lt;K, V&gt; { }
<i>// A variable of a generic instance type.</i>
var map : Dict&lt;String, Int&gt;
</pre>
<!-- ===================================================================== -->
<h3 id="type-tuple">Tuple Types</h3>
<!-- ===================================================================== -->
<div class="commentary">
Tuples are everywhere in Swift: even the argument list of a function is a
tuple of those arguments.
</div>
<pre class="grammar">
type-tuple ::= '(' type-tuple-body? ')'
type-tuple-body ::= type-tuple-element (',' type-tuple-element)* '...'?
type-tuple-element ::= identifier ':' <a href="#type">type-annotation</a>
type-tuple-element ::= <a href="#type">type-annotation</a>
</pre>
<p>Syntactically, tuple types are simply a (possibly empty) list of
elements enclosed in parentheses. A tuple type with a single, anonymous
element is exactly that type: the parentheses are treated as
grouping parentheses.</p>
<p>Tuples are the low-level form of data aggregation in Swift, and are used as
the building block of <a href="#type-function">function</a> argument lists,
multiple return values, <a href="#decl-union">union</a> bodies, etc. Because
tuples are widely accessible and available everywhere in the language,
aggregate data access and transformation is uniform and powerful.</p>
<p>Each element of a tuple contains an optional name followed by a type.</p>
<p>If the tuple body ends with '...', the tuple is a varargs tuple. The type
of the last element is changed from T to T[], and there are special rules
for converting an expression to varargs tuple type.</p>
<pre class="example">
<i>// Variable definitions.</i>
var a : ()
var b : (Int, Int)
var c : (x : (), y : Int)
<i>// Tuple type inferred from an initializers:</i>
var m = () <i>// Type = ()</i>
var n = (x = 1, y = 2) <i>// Type = (x : Int, y : Int)</i>
var o = (1, 2, 3) <i>// Type = (Int, Int, Int)</i>
<i>// Function argument and result is a tuple type.</i>
func foo(x : Int, y : Int) -&gt; (val : Int, err : Int)
<i>// union and struct declarations with tuple values.</i>
struct S {
var (a : Int, b : Int)
}
union Vertex {
case Point2(x : Int, y : Int)
case Point3(x : Int, y : Int, z : Int)
case Point4(w : Int, x : Int, y : Int, z : Int)
}
</pre>
<!-- ===================================================================== -->
<h3 id="type-function">Function Types</h3>
<!-- ===================================================================== -->
<pre class="grammar">
type-function ::= <a href="#type">type-tuple</a> '-&gt;' <a href="#type">type</a>
</pre>
<p>Function types have a single input and single result type, separated by
an arrow. Because each of the types is allowed to be a tuple, we trivially
support multiple arguments and multiple results. "Function" types are
more properly known as a "closure" type, because they can embody any
context captured when the function value was formed.</p>
<p>The result type of a function type must
be <a href="#materializable">materializable</a>. The argument type of a
function is always required to be parenthesized (a tuple). The behavior
of function types may be modified with the <a
href="#attribute-auto_closure"><tt>auto_closure</tt> attribute</a>.</p>
<p>Because of the grammar structure, a nested function type like
"(a) -&gt; (b) -&gt; c" is parsed as "(a) -&gt; ((b) -&gt; c)". This means
that if
you declare this that you can pass it one argument to get a function that
"takes b and returns c" or you can pass two arguments to "get a c". This
is known as <a href="http://en.wikipedia.org/wiki/Currying">currying</a>.
For example:
</p>
<pre class="example">
<i>// A simple function that takes a tuple and returns Int:</i>
var a : (a : Int, b : Int) -&gt; Int
<i>// A simple function that returns multiple values:</i>
var a : (a : Int, b : Int) -&gt; (val: Int, err: Int)
<i>// Declare a function that returns a function:</i>
var x : (Int) -&gt; (Int) -&gt; Int
<i>// y has type (Int) -&gt; Int</i>
var y = x(1)
<i>// z1 and z2 both has type Int, and both have the same value (assuming
// the function had no side effects).</i>
var z1 = x(1)(2)
var z2 = y(2)
<i>// An auto closure value. This captures an implicit closure over the</i>
<i>// specified expression, instead of the expression itself.</i>
var a : [auto_closure] () -> Int = 4
</pre>
<!-- ===================================================================== -->
<h3 id="type-union">Union Types</h3>
<!-- ===================================================================== -->
<div class="commentary">
'union' types are known as <a
href="http://en.wikipedia.org/wiki/Algebraic_data_type">algebraic data
types</a> by the broader programming language community. The name 'union'
is inspired by C's unions, though Swift's are much safer.
</div>
<p>A union type is a simple discriminated union: the runtime representation
of a value of union type only has one of the specified elements at a time.</p>
<p>All of the element types of a union type must
be <a href="#materializable">materializable</a>.</p>
<p>A union type is defined by a <a href="#decl-union">union decl</a>.
<p>Values of union type may not be default initialized unless the user
provides a no-argument constructor.</p>
<p>The union metatype has a member corresponding to each declared element.
For elements with a declared type, this member is a function which can
construct a union containing that element. For elements without a
declared type, the member is simply a union value for that element. A
union value has no accessible members except those explicitly defined
by the user.</p>
<p>A reference to a member of the union metatype can be shortened using <a
href="#expr-delayed-identifier">delayed identifier resolution</a>
with <a href="#typecheck_context">context sensitive type inference</a>.
</p>
<p>The union's value can be tested and accessed by pattern-matching the union
against a <a href="#pattern-union-element">union element pattern</a>.
<p>TODO: Should attributes be allowed on union elements?
TODO: Eventually, with generics we'll have equality and inequality operators.
Union decls should be able to implicitly define these for their types.
TODO: Need pattern matching and element extraction.
</p>
<!-- ===================================================================== -->
<h3 id="type-array">Array Types</h3>
<!-- ===================================================================== -->
<div class="commentary">
Note that array types are parsed inside-out, with the first
bounds clause being the outermost one. This little oddity is required
for the bounds of nested arrays to correspond in sequence to subscript
indexes. That is, given an array "x : Int[5][7][11][13]" and a
chained subscript expression of the form "x[i][j][k][l]", we really
want "i" to be bounded by 5, "j" by 7, and so on. This is probably
the only case where C's rule of "declaration follows use" really makes
sense. There's precedent for this in many languages, including Java and C#.
</div>
<pre class="grammar">
type-array ::= <a href="#type">type-simple</a>
type-array ::= <a href="#type">type-array</a> '[' ']'
type-array ::= <a href="#type">type-array</a> '[' <a href="#expr">expr</a> ']'
</pre>
<p>Array types include a base type and an optional size. Array types indicate
a linear sequence of elements stored consequtively memory. Array elements may
be efficiently indexed in constant time. All array indexes are bounds checked
and out of bound accesses are diagnosed with either a compile time or
runtime failure (TODO: runtime failure mode not specified).</p>
<p>While they look syntactically very similar, an array type with a size has
very different semantics than an array without. In the former case, the type
indicates a declaration of actual storage space. In the later case, the type
indicates a <em>reference</em> to storage space allocated elsewhere of
runtime-specified size.
</p>
<p>FIXME: We should separate out "Arrays" from "Slices". Arrays should always
require a size and is by-value, a slice is a by-ref and never have a
(statically specified) size.</p>
<p>For an array with a size, the size must be more than zero (no
indices would be valid). For now, the array size must be a literal integer.
TODO: Define a notion like C's integer-constant-expression for how constant
folding works.</p>
<p>The element type of an array type must
be <a href="#materializable">materializable</a>.</p>
<p>FIXME: Int[][] not valid because the element type isn't sized. We need
some constraint to reject this, or do we?</p>
<p>Some example array types:</p>
<pre class="example">
<i>// A simple array declaration:</i>
var a : Int[4]
<i>// A reference to another array:</i>
var b : Int[] = a
<i>// Declare a two dimensional array:</i>
var c : Int[4][4]
<i>// Declare a reference to another array, two dimensional:</i>
var d : Int[4][]
<i>// Declare an array of function pointers:</i>
var array_fn_ptrs : (: (Int) -&gt; Int)[42]
var g = array_fn_ptrs[12](4)
<i>// Without parens, this is a function that returns a fixed size array:</i>
var fn_returning_array : (Int) -&gt; Int[42]
var h : Int[42] = fn_returning_array(4)
<i>// You can even have arrays of tuples and other things, these work right
// through composition:</i>
var array_of_tuples : (a : Int, b : Int)[42]
var tuple_of_arrays : (a : Int[42], b : Int[42])
array_of_tuples[12].a = array_of_tuples[13].b
tuple_of_arrays.a[12] = array_of_tuples.b[13]
</pre>
<!-- _____________________________________________________________________ -->
<h3 id="type-metatype">Metatype Types</h3>
<pre class="grammar">
type-metatype ::= type-simple '.' 'metatype'
</pre>
<p>Every type has an associated metatype. A value of the metatype
type is a reference to a global object which describes the type.
Most metatype types are singleton and therefore require no
storage, but metatypes associated with <a href="#decl-class">class
types</a> follow the same subtyping rules as their associated
class types and therefore are not singleton.</p>
<!-- _____________________________________________________________________ -->
<h3 id="type-optional">Optional Types</h3>
<div class="commentary">
Similar constructs exist in Haskell (<a
href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-Maybe.html">Maybe</a>),
the Boost library (<a
href="http://www.boost.org/doc/libs/1_54_0/libs/optional/doc/html/index.html">Optional</a>),
and C++14 (<a href="http://en.cppreference.com/w/cpp/utility/optional">optional</a>).
</div>
<pre class="grammar">
type-optional ::= type-simple '?'
</pre>
<p>An optional type is syntactic sugar for the library type
Optional&lt;T&gt;. This is a <a href="#decl-union">union</a> with two
cases: None and Some, used to represent a value that may or may not be
present.</p>
<p>FIXME: The current implementation of Optional is a hack and None and
Some are currently both globals rather than members.</p>
<p>Optional types are different from other unions in that any value
<code>x</code> is implicitly convertible to Some(<code>x</code>). This is
part of the language, not the library; therefore, the libary type Optional
is required to have a constructor that accepts a single argument.</p>
<p>Since optional types are part of the
<a href="#type-simple">type-simple</a> grammar, it is not possible to write
<code>T[]?</code> for an optional array. Use <code>(T[]?)</code> instead.
</p>
<p>Some example optional types:</p>
<pre class="example">
<i>// A simple optional declaration:</i>
var a : Int? // equivalent to Optional&lt;Int&gt;
<i>// An empty optional:</i>
var b : Int? = .None
<i>// Declare an array of optionals:</i>
var c : Int?[] = new Int?[4]
</pre>
<!-- _____________________________________________________________________ -->
<h3 id="type-composition">Protocol Composition Types</h3>
<pre class="grammar">
type-composition ::= 'protocol' '&lt;' type-composition-list? '&gt;'
type-composition-list ::= <a href="#type-identifier">type-identifier</a> (',' <a href="#type-identifier">type-identifier</a>)*
</pre>
<p>A protocol composition type composes together a number of
protocols to describe a type that meets the requirements of each of
those protocols. A protocol composition type <code>protocol&lt;A,
B&gt;</code> is similar to an explicitly-defined protocol that
inherits both <code>A</code> and <code>B</code></p>
<pre class="example">
protocol C : A, B { }
</pre>
<p>but without the need to introduce a new name.</p>
<div class="commentary">
If we drop implicit conformance to protocols, protocol composition
types become much more important, because they allow you to give a
name to a composition without requiring types to explicitly
conform to that name.
</div>
<p>Each of the types named in the
<code>type-composition-list</code> shall refer to either a protocol
or to a protocol composition. The list may be empty, in which case
every type conforms to the empty protocol composition. This is how
the <code>Any</code> type is defined in the standard library.</p>
<pre class="example">
<i>// A value that represents any type</i>
var any : protocol&lt;&gt; = 17
<i>// A value that conforms to both the Document and Enumerator protocols</i>
var doc : protocol&lt;Document,Enumerator&gt;
doc.isEmpty() <i>// uses Enumerator.isEmpty()</i>
doc.title = "Hello" <i>// uses Document.title</i>
</pre>
<!-- _____________________________________________________________________ -->
<h3 id="inheritance">Type Inheritance</h3>
<pre class="grammar">
inheritance ::= ':' <a href="#type-identifier">type-identifier</a> (',' <a href="#type-identifier">type-identifier</a>)*
</pre>
<p>A named type (e.g., a class, struct, union, or protocol) can
"inherit" some set of protocols, which implies that any object of
that type conforms to each of those protocols. When a protocol
inherits other protocols, the set of requirements from all of those
protocols is effectivel aggregated into the protocol, and a type that
conforms to the current protocol shall conform to each of the
protocols that it inherits.</p>
<p>When a non-protocol type inherits a protocol, it is specifying
explicitly that it conforms to that protocol. The program is
ill-formed if the type does not conform to the protocol.</p>
<pre class="example">
protocol VersionedDocument : Document { <i>// every VersionedDocument is a Document</i>
func bumpVersion()
}
func print(doc : Document) { <i>/* ... */</i> }
var myDocument : VersionedDocument;
print(myDocument) <i>// okay: a VersionedDocument is a Document</i>
class StoredHTML : VersionedDocument { <i>// okay: StoredHTML conforms to VersionedDocument</i>
var Title : String
func bumpVersion()
}
</pre>
<!-- ********************************************************************* -->
<h2 id="pattern">Patterns</h2>
<!-- ********************************************************************* -->
<div class="commentary">
The pattern grammar mirrors the expression grammar, or to be more
specific, the grammar of literals. This is because the conceptual
algorithm for matching a value against a pattern is to try to find
an assignment of values to variables which makes the pattern equal
the value. So every expression form which can be used to build a
value directly should generally have a corresponding pattern form.
</div>
<pre class="grammar">
pattern-atom ::= <a href="#pattern-var">pattern-var</a>
pattern-atom ::= <a href="#pattern-any">pattern-any</a>
pattern-atom ::= <a href="#pattern-tuple">pattern-tuple</a>
pattern-atom ::= <a href="#pattern-is">pattern-is</a>
pattern-atom ::= <a href="#pattern-union-element">pattern-union-element</a>
pattern-atom ::= <a href="#pattern-expr">expr</a>
pattern ::= pattern-atom
pattern ::= <a href="#pattern-typed">pattern-typed</a>
</pre>
<p>A pattern represents the structure of a composite value.
Parts of a value can be extracted and bound to variables or compared
against other values by <i>pattern matching</i>. Among other places,
pattern matching occurs on the left-hand side of
<a href="#decl-var"><tt>var</tt> bindings</a>, in the arguments of
<a href="#decl-func"><tt>func</tt> declarations</a>, and in the
<tt>case</tt> labels of
<a href="#stmt-switch"><tt>switch</tt> statements</a>.
Some examples:</p>
<pre class="example">
var point = (1, 0, 0)
<i>// Extract the elements of the "point" tuple and bind them to
// variables x, y, and z.</i>
var (x, y, z) = point
println("x=\(x) y=\(y) z=\(z)")
<i>// Dispatch on the elements of a tuple in a "switch" statement.</i>
switch point {
case (0, 0, 0):
println("origin")
<i>// The pattern "_" matches any value.</i>
case (_, 0, 0):
println("on the x axis")
case (0, _, 0):
println("on the y axis")
case (0, 0, _):
println("on the z axis")
case (var x, var y, var z):
println("x=\(x) y=\(y) z=\(z)")
}
</pre>
<p>A pattern may be "irrefutable", meaning informally that it
matches all values of its type. Patterns in declarations, such as
<a href="#decl-var"><tt>var</tt></a> and
<a href="#decl-func"><tt>func</tt></a>, are required to be irrefutable.
Patterns in the <tt>case</tt> labels of
<a href="#stmt-switch"><tt>switch</tt> statements</a>, however,
are not.</p>
<p>The basic pattern grammar is a literal "atom" followed by an
optional type annotation. Type annotations are useful for
documentation, as well as for coercing a matched expression to a
particular kind. They are also required when patterns are used in
a <a href="#func-signature">function signature</a>. Type annotations
are currently not allowed in switch statements.</p>
<p>A pattern has a type. A pattern may be "fully-typed", meaning
informally that its type is fully determined by the type
annotations it contains. Some patterns may also derive a type
from their context, be it an enclosing pattern or the way it is
used; this set of situations is not yet fully determined.</p>
<!-- ********************************************************************* -->
<h3 id="pattern-typed">Typed Patterns</h3>
<!-- ********************************************************************* -->
<pre class="grammar">
pattern-typed ::= pattern-atom ':' <a href="#type">type-annotation</a>
</pre>
<p>A type annotation constrains a pattern to have a specific type.
An annotated pattern is fully-typed if its annotation type is
fully-typed. It is irrefutable if and only if its subpattern is
irrefutable.</p>
<p>Type annotations are currently not allowed in the <tt>case</tt> labels
of <tt>switch</tt> statements; case patterns always get their type from
the subject of the switch.</p>
<!-- ********************************************************************* -->
<h3 id="pattern-any">Any Patterns</h3>
<!-- ********************************************************************* -->
<pre class="grammar">
pattern-any ::= '_'
</pre>
<p>The symbol <tt>_</tt> in a pattern matches and ignores any value. It
is irrefutable.</p>
<!-- ********************************************************************* -->
<h3 id="pattern-var">'var' Patterns</h3>
<!-- ********************************************************************* -->
<pre class="grammar">
pattern-var ::= 'var' pattern
</pre>
<p>The keyword <tt>var</tt> within a pattern introduces variable bindings.
Any identifiers within the subpattern bind new named variables to their
matching values.<p>
<pre class="example">
var point = (0, 0, 0)
switch point {
<i>// Bind x, y, z to the elements of point.</i>
case (var x, var y, var z):
println("x=\(x) y=\(y) z=\(z)")
}
switch point {
<i>// Same. 'var' distributes to the identifiers in its subpattern.</i>
case var (x, y, z):
println("x=\(x) y=\(y) z=\(z)")
}
</pre>
<p>Outside of a <tt>var</tt> pattern, an identifier behaves as an
<a href="#pattern-expr">expression pattern</a> referencing an existing
definition.</p>
<pre class="example">
var zero = 0
switch point {
<i>// x and z are bound as new variables.
// zero is a reference to the existing 'zero' variable.</i>
case (var x, zero, var z):
println("point off the y axis: x=\(x) z=\(z)")
default:
println("on the y axis")
}
</pre>
<p>The left-hand pattern of a <a href="#decl-var"><tt>var</tt> declaration</a>
and the argument pattern of a <a href="#decl-func"><tt>func</tt> declaration</a>
are implicitly inside a <tt>var</tt> pattern; identifiers in their patterns
always bind variables. Variable bindings are irrefutable.</p>
<p>The type of a bound variable must be
<a href="#materializable">materializable</a> unless it appears in a
<a href="#function-signature">function-signature</a> and is directly of
a <a href="attribute-byref"><tt>byref</tt></a>-annotated type.</p>
<!-- ********************************************************************* -->
<h3 id="pattern-tuple">Tuple Patterns</h3>
<!-- ********************************************************************* -->
<pre class="grammar">
pattern-tuple ::= '(' pattern-tuple-body? ')'
pattern-tuple-body ::= pattern-tuple-element (',' pattern-tuple-body)* '...'?
pattern-tuple-element ::= pattern
pattern-tuple-element ::= pattern '=' <a href="#expr">expr</a>
</pre>
<p>A tuple pattern is a list of zero or more patterns. Within a
function signature, patterns may also be given a default-value
expression.</p>
<p>A tuple pattern is irrefutable if all its sub-patterns are
irrefutable.</p>
<p>A tuple pattern is fully-typed if all its sub-patterns are
fully-typed, in which case its type is the corresponding tuple
type, where each <tt>type-tuple-element</tt> has the type,
label, and default value of the corresponding <tt>pattern-tuple-element</tt>.
A <tt>pattern-tuple-element</tt> has a label if it is a named
pattern or a type annotation of a named pattern.</p>
<p>A tuple pattern whose body ends in <tt>'...'</tt> is a varargs tuple.
The last element of such a tuple must be a typed pattern, and the type
of that pattern is changed from <tt>T</tt> to <tt>T[]</tt>. The
corresponding tuple type for a varargs tuple is a varargs tuple type.</p>
<p>As a special case, a tuple pattern with one element that has no
label, has no default value, and is not varargs is treated as a
grouping parenthesis: it has the type of its constituent pattern,
not a tuple type.</p>
<!-- ********************************************************************* -->
<h3 id="pattern-is">'is' Patterns</h3>
<!-- ********************************************************************* -->
<pre class="grammar">
pattern-is ::= 'is' <a href="#type">type</a>
</pre>
<p><tt>is</tt> patterns perform a type check equivalent to the
<tt>x is T</tt> <a href="#expr-cast">cast operator</a>. The pattern matches
if the runtime type of a value is of the given type. <tt>is</tt> patterns
are refutable and thus cannot appear in declarations.</p>
<pre class="example">
class B {}
class D1 : B {}
class D2 : B {}
var bs : B[] = [B(), D1(), D2()]
for b in bs {
switch b {
case is B:
println("B")
case is D1:
println("D1")
case is D2:
println("D2")
}
}
</pre>
<!-- ********************************************************************* -->
<h3 id="pattern-union-element">Union Element Patterns</h3>
<!-- ********************************************************************* -->
<pre class="grammar">
pattern-union-element ::= <a href="#type-identifier">type-identifier</a>? '.' identifier <a href="#pattern-tuple">pattern-tuple</a>?
</pre>
<p>Union element patterns match a value of
<a href="#type-union">union type</a> if the value matches the referenced
<tt>case</tt> of the union. If the <tt>case</tt> has a type, the value
of that type can be matched against an optional subpattern.</pre>
<pre class="example">
union HTMLTag {
case A(href:String)
case IMG(src:String, alt:String)
case BR
}
switch tag {
case .BR:
println("&lt;br&gt;")
case .IMG(var src, var alt):
println("&lt;img src=\"\(escape(src))\" alt=\"\(escape(alt))\"&gt;")
case .A(var href):
println("&lt;a href=\"\(escape(href))\"&gt;")
}
</pre>
<p>Union element patterns are refutable and thus cannot appear in
declarations.
(They are currently considered refutable even if the union contains only
a single <tt>case</tt>.)
<!-- ********************************************************************* -->
<h3 id="pattern-expr">Expressions in Patterns</h3>
<!-- ********************************************************************* -->
<p>Patterns may include arbitrary expressions as subpatterns. Expression
patterns are refutable and thus cannot appear in declarations. An expression
pattern is compared to its corresponding value using the <tt>~=</tt>
operator. The match succeeds if <tt>expr ~= value</tt> evaluates to true.
The standard library provides a default implementation of <tt>~=</tt>
using <tt>==</tt> equality; additionally, range objects may be matched
against integer and floating-point values. The <tt>~=</tt> operator may
be overloaded like any function.</p>
<pre class="example">
var point = (0, 0, 0)
switch point {
<i>// Equality comparison.</i>
case (0, 0, 0):
println("origin")
<i>// Range comparison.</i>
case (-10..10, -10..10, -10..10):
println("close to the origin")
default:
println("too far away")
}
<i>// Define pattern matching of an integer value to a string expression.</i>
func ~=(pattern:String, value:Int) -&gt; Bool {
return pattern == "\(value)"
}
<i>// Now we can pattern-match strings to integers:</i>
switch point {
case ("0", "0", "0"):
println("origin")
default:
println("not the origin")
}
</pre>
<p>The order of evaluation of expressions in patterns, including whether an
expression is evaluated at all, is unspecified. The compiler is free to
reorder or elide expression evaluation in patterns to improve dispatch
efficiency. Expressions in patterns therefore cannot be relied on for
side effects.</p>
<!-- ********************************************************************* -->
<h2 id="expr">Expressions</h2>
<!-- ********************************************************************* -->
<div class="commentary">
Support for user-defined operators causes some amount of parsing
to be delayed until after name resolution has occurred. Other
restrictions and disambiguations in the grammar permit the parser
to decide all other aspects of parsing, such as where statements
must be divided.<br><br>
Semicolons in C are generally just clutter. Swift generally tries
to define away the need for them.
</div>
<pre class="grammar">
expr ::= expr-basic
expr ::= <a
href="#expr-trailing-closure">expr-trailing-closure</a> <a href="#expr-cast">expr-cast</a>?
expr-basic ::= expr-sequence <a href="#expr-cast">expr-cast</a>?
expr-sequence ::= <a href="#expr-unary">expr-unary</a> <a href="#expr-binary">expr-binary</a>*
expr-primary ::= <a href="#expr-literal">expr-literal</a>
expr-primary ::= <a href="#expr-identifier">expr-identifier</a>
expr-primary ::= <a href="#expr-super">expr-super</a>
expr-primary ::= <a href="#expr-closure">expr-closure</a>
expr-primary ::= <a href="#expr-anon-closure-arg">expr-anon-closure-arg</a>
expr-primary ::= <a href="#expr-paren">expr-paren</a>
expr-primary ::= <a href="#expr-delayed-identifier">expr-delayed-identifier</a>
expr-postfix ::= expr-primary
expr-postfix ::= expr-postfix <a href="#operator">operator-postfix</a>
expr-postfix ::= <a href="#expr-new">expr-new</a>
expr-postfix ::= <a href="#expr-dot">expr-dot</a>
expr-postfix ::= <a href="#expr-metatype">expr-metatype</a>
expr-postfix ::= <a href="#expr-subscript">expr-subscript</a>
expr-postfix ::= <a href="#expr-call">expr-call</a>
</pre>
<p>At the top level of the expression grammar, expressions are a
sequence of unary expressions joined by binary operators. When
parsing an expr, a binary operator immediately following an
expr-unary continues the expression, and the program is ill-formed
if it is not then followed by another expr-unary. This resolves
an ambiguity which could otherwise arise in statement contexts due
to semicolon elision.</p>
<pre class="example">
5 !- +~123 -+- ~+6
(foo)(())
bar(49+1)
baz()
</pre>
<p>A unary or binary expression may optionally be followed by a
<a href="#expr-cast">cast operator</a>.
<!-- ===================================================================== -->
<h3 id="expr-binary">Binary Operators</h3>
<!-- ===================================================================== -->
<div class="commentary">
Should this use the expr-identifier production to allow qualified
identifiers? This would allow "foo swift.+ bar". Is ADL or something
like it enough?<br><br>
</div>
<pre class="grammar">
expr-binary ::= op-binary-or-ternary <a href="#expr-unary">expr-unary</a> expr-cast?
op-binary-or-ternary ::= <a href="#operator">operator-binary</a>
op-binary-or-ternary ::= '='
op-binary-or-ternary ::= '?' <a href="#expr">expr-sequence</a> ':'
expr-cast ::= 'is' <a href="#type">type</a>
expr-cast ::= 'as' <a href="#type">type</a>
expr-cast ::= 'as' '!' <a href="#type">type</a>
</pre>
<p>Infix binary expressions are not formed during parsing. Instead,
they are formed after name resolution by building a tree from an
operator-delimited sequence of unary expressions. Precedence and
associativity are determined by the <a href="#attribute-infix">infix</a>
attribute on the resolved names, which must fully agree.</p>
<p>If an operator is used as a binary operator, but name resolution
does not find at least one function of binary operator type, the
expression is ill-formed.</p>
<p>A simple example is:</p>
<pre class="example">
4 + 5 * 123
</pre>
<!-- ===================================================================== -->
<h3 id="expr-binary-builtin">Builtin Binary Operators</h3>
<!-- ===================================================================== -->
<p>In addition to user-defined operators, a handful of builtin operators are
defined that parse inside binary expressions with predefined precedence and
associativity.
<h4 id="expr-assign">Assignment operator</h4>
<p>The assignment operator <tt>a = b</tt> updates the value of <tt>a</tt> with
the value of <tt>b</tt>. Its precedence is hardcoded as if declared as
follows:</p>
<pre class="example">
// Not valid Swift code
operator infix = {
precedence 90
associativity right
}
</pre>
The left-hand operand must be an lvalue, or a tuple of lvalues. Assigning to
a tuple of lvalues performs destructuring reassignment.
<pre class="example">
var (a, b) = (1, 2)
// Swap two values.
(a, b) = (b, a)
// Reassign two values.
(a, b) = (11, 22)
// Reassign two values by destructuring a tuple.
var tuple = (111, 222)
(a, b) = tuple
</pre>
<p>An assignment expression evaluates to void. Unlike C, productions such as
these are invalid:</p>
<pre class="example">
// Error: x = y doesn't return Bool
if x = y { }
// Error: (y = z) doesn't return Int
var x, y, z : Int
x = y = z
</pre>
<h4 id="expr-ternary">Ternary operator</h4>
<p>The ternary operator <tt>a ? b : c</tt> conditionally evaluates its middle
or right operand based on the value of its left operand. Its precedence is
hardcoded as if the middle <tt>? b :</tt> subexpression were a binary operator
declared as follows:</p>
<pre class="example">
// Not valid Swift code
operator infix ?...: {
precedence 100
associativity right
}
</pre>
<p>The subexpression to the left of the
'?' is evaluated, and is converted to 'Bool' using the result's
'getLogicValue' method if it is not already 'Bool'. If the condition is
true, the subexpression to the right of '?' is evaluated, and its result
becomes the result of the expression. If the
condition is false, the subexpression to the right of ':' is evaluated, and
its result becomes the result of the expression. Only one of the
'?' or ':' subexpressions will be evaluated. The results of the
'?' and ':' subexpressions must be implicitly convertible to a common type,
which becomes the type of the ternary expression.
<pre class="example">
x += b ? y : z
x += a ? b ? y : z : w
for i in 1..101 {
println(i % 15 ? "fizzbuzz"
: i % 3 == 0 ? "fizz"
: i % 5 == 0 ? "buzz"
: "\(i)")
}
</pre>
<h4 id="expr-cast">Cast operators</h4>
<p>Cast expressions influence the types of their subexpressions. They can appear
at the end of a binary operator sequence; their left operand is parsed as if
the cast operators were declared as follows:</p>
<pre class="example">
// Not valid Swift code
operator infix as {
precedence 95
associativity none
}
</pre>
<p>The right operand of all operators is parsed as a type.</p>
<ul>
<li><tt>x as T</tt> will coerce the expression <tt>x</tt> to the type T.
<tt>x</tt> must be implicitly convertible to <tt>T</tt>; in other words,
<tt>var foo:T = x</tt> must be valid. <tt>as</tt> may be used to provide
type annotations for literals with insufficient contextual type information,
or to force implicit conversions. Some examples:
<pre class="example">
7 as Double // The literal 7 coerced to a Double
{ $0 + $1 } as (Int, Int) -&gt; Int // A function coerced to a function type
class B { }
class D : B { }
new D as B // A subclass instance coerced to a superclass.
</pre>
A cast that can fail, such as from a superclass to a subclass, cannot
be expressed with <tt>as</tt>.
<li><tt>x as! T</tt> will try to cast the value of the expression
<tt>x</tt> to a subtype of its compile-time type. The type of the value is
checked at runtime, and if the cast cannot succeed, the program terminates.
<tt>T</tt> must be a subtype of the compile-time type of <tt>x</tt>.
An example:
<pre class="example">
var b:B = new D
var d = b as! D
</pre>
<li><tt>x is T</tt> will query the type of the value of <tt>x</tt> at runtime.
<tt>T</tt> must be a subtype of the compile-time type of <tt>x</tt>.
If the runtime value of <tt>x</tt> is <tt>T</tt>, the <tt>is</tt> expression
evaluates to true; otherwise, it evaluates to false.
<pre class="example">
if b is D {
var d = b as! D
}
</pre>
</ul>
<p><tt>as</tt>, <tt>as!</tt>, and <tt>is</tt> all parse a type for their
right-hand argument. They must be parenthesized if followed by subsequent
operators:
<pre class="example">
(b as! D).derivedMethod()
((D as B) as! D2)
(b is D) ? (b as! D) : new D
</pre>
<!-- ===================================================================== -->
<h3 id="expr-unary">Unary Operators</h3>
<!-- ===================================================================== -->
<pre class="grammar">
expr-unary ::= <a href="#operator">operator-prefix</a>* <a href="#expr">expr-postfix</a>
</pre>
<p>If an operator is used as a unary operator, but name resolution
does not find at least one function that takes a single argument, the
expression is ill-formed.</p>
<p>Simple examples:</p>
<pre class="example">
i = -j
</pre>
<!-- ===================================================================== -->
<h3 id="expr-literal">Literals</h3>
<!-- ===================================================================== -->
<div class="commentary">
The type of a literal is inferred from its context, to allow things like "4"
to be compatible with any width integer type without 'promotion' rules or
casting. In ambiguous cases like "var x = 4", the literals are forced to
a default type specified by the standard library.
</div>
<pre class="grammar">
expr-literal ::= <a href="#integer_literal">integer_literal</a>
expr-literal ::= <a href="#floating_literal">floating_literal</a>
expr-literal ::= <a href="#character_literal">character_literal</a>
expr-literal ::= <a href="#string_literal">string_literal</a>
expr-literal ::= '__FILE__'
expr-literal ::= '__LINE__'
expr-literal ::= '__COLUMN__'
</pre>
<p>Numeric literals are either integer, floating point, character, or string
depending on its lexical form. The type of the literal is inferred
based on its context. If there is no contextual type information for an
expression, all unresolved types are inferred to 'IntegerLiteralType'
type, to 'FloatLiteralType', to 'CharacterLiteralType', and to
'StringLiteralType', respectively.
If a literal is used and these types are not defined, then the code is
malformed.</p>
<p>A literal is compatible with its inferred type if that type implements an
informal protocol required by literals. This informal protocol requires
that the type have an unambiguous "static" function defined whose
result type is the same as the inferred type, and that takes a single
argument that is either itself literal compatible, or is a <a
href="#builtin">builtin</a> integer type.</p>
<p>The '<tt>__FILE__</tt>', '<tt>__LINE__</tt>', and '<tt>__COLUMN__</tt>'
magic identifiers expand to a literal representation of their position in
the source code. '<tt>__FILE__</tt>' expands to a string literal;
'<tt>__LINE__</tt>' and '<tt>__COLUMN__</tt>' each expand to an integer
literal.</p>
<pre class="example">
<i>// File foo.swift</i>
var file = __FILE__ <i>// file : String = "foo.swift"</i>
var line = __LINE__ <i>// line : Int = 4</i>
var col = __COLUMN__ <i>// column : Int = 11</i>
</pre>
<p>If '<tt>__FILE__</tt>', '<tt>__LINE__</tt>', and/or '<tt>__COLUMN__</tt>'
are used as default argument values in a function declaration, they
instead expand to the source location of each function call that
instantiates the default argument.</p>
<pre class="example">
func log(message:String,
file:String = __FILE__,
line:Int = __LINE__) {
println("\(file):\(line): \(message)")
}
log("Orders received")
doIt()
log("Job's finished")
</pre>
<!-- ===================================================================== -->
<h3 id="expr-identifier">Identifiers</h3>
<!-- ===================================================================== -->
<pre class="grammar">
expr-identifier ::= <a href="#identifier">identifier</a> <a href="#type-identifier">generic-params</a>?
</pre>
<p>A raw identifier refers to a value found via <a
href="#namebind_value_lookup_unqual">unqualified value lookup</a>, and has
the type of the declaration returned by name lookup and overload
resolution. Value declarations are installed with <a
href="#decl-var">var</a> and the syntactic sugar forms like <a
href="decl-func">func</a> declarations.</p>
<p>If an identifier refers to a generic type, an instance of that generic may
be referenced by following the identifier with a list of type parameters
enclosed in angle brackets <tt>&lt;&gt;</tt>:</p>
<pre class="example">
<i>// A generic struct.</i>
struct Dict&lt;K,V&gt; {
constructor() {}
static func fromKeysAndValues(keys:K[], values:T[]) -&gt; Dict&lt;K,V&gt; {}
}
<i>// Construct an instance of the generic struct.</i>
var foo = Dict&lt;String, Int&gt;()
<i>// Invoke a static method of an instance of the generic struct.</i>
var bar = Dict&lt;String, Int&gt;.fromKeysAndValues(
["zim", "zang", "zung"],
[ 123, 456, 789 ])
</pre>
<h4 id="expr-generic-disambiguation">Generic disambiguation</h4>
<p>Note that <tt>&lt;</tt> and <tt>&gt;</tt> are used as both angle brackets in
<a href="#expr-identifier">generic identifiers</a> and as characters in
<a href="#expr-binary">binary operator</a> names. Because of this, there are
potential parsing ambiguities. Swift uses a context-free heuristic to
determine whether to parse an expression involving <tt>&lt;</tt> and <tt>&gt;</tt>
as a generic parameter list or a binary operator:
<ul>
<li>When an <a href="#identifier">identifier</a> is followed by <tt>&lt;</tt>,
Swift attempts to parse starting from the <tt>&lt;</tt> as a
<a href="#type-identifier">generic parameter list</a>.
<li>If it succeeds in parsing a generic parameter list, it looks at the
token after the closing <tt>&gt;</tt>. If it sees one of the following tokens:
<blockquote>
<tt>( [ { } ] ) . , ;</tt>
</blockquote>
then the expression is parsed as a generic parameter list.
<li>If Swift cannot parse a generic parameter list after the <tt>&lt;</tt>,
or the matching <tt>&gt;</tt> is not followed by one of the above tokens,
the <tt>&lt;</tt> is parsed as an operator character.
</ul>
<p>These rules assume that, in most cases, generic type names will be used
in constructor expressions as in <tt>Foo&lt;T&gt;(x)</tt> or to access static
members as in <tt>Foo&lt;T&gt;.bar()</tt>. Referring to a generic metatype as a
value in an expression may require parentheses around the type name.
<pre class="example">
<i>// An operator that operates on metatypes.</i>
func [infix] +-+ &lt;T, U&gt;(t:T.metatype, u:U.metatype) -&gt; Foo { }
var foo = (Dict&lt;String, Int&gt;) +-+ (Slice&lt;Char&gt;)
println(foo)
</pre>
<p>On the other hand, some expressions involving <tt>&lt;</tt> and
<tt>&gt;</tt> operators may misparse as generic arguments as well. These
can also be corrected by adding or removing parentheses.
<pre class="example">
func foo(x:Bool, y:Bool)
var a,b,c,d,e : Int
foo(a &lt; b, c &gt; (d + e)) // ERROR: Misparses as (a&lt;b,c&gt;)(d + e)
foo((a &lt; b), c &gt; (d + e)) // Force parsing as (a &lt; b), (c &gt; (d + e))
foo(a &lt; b, c &gt; d + e) // Also parses as (a &lt; b), (c &gt; (d + e))
</pre>
<!-- ===================================================================== -->
<h3 id="expr-super">Super</h3>
<!-- ===================================================================== -->
<pre class="grammar">
expr-super ::= expr-super-method
expr-super ::= expr-super-subscript
expr-super ::= expr-super-constructor
expr-super-method ::= 'super' '.' <a href="#expr-identifier">expr-identifier</a>
expr-super-subscript ::= 'super' '[' <a href="#expr">expr</a> ']'
expr-super-constructor ::= 'super' '.' 'constructor'
</pre>
<p>The keyword <tt>super</tt> is used to refer to superclass members from
a subclass method. This can be used to access members of a superclass
overridden by the subclass. The following forms are allowed:
<ul>
<li>A superclass property or method can be accessed with the form
<tt>super.name</tt>.</li>
<li>A superclass subscript accessor can be accessed with the form
<tt>super[index]</tt>.</li>
<li>Within a constructor, a superclass constructor can be accessed with the
form <tt>super.constructor</tt>.</li>
</ul>
<p><tt>super</tt> expressions are invalid outside of a subclass method.
<tt>super.constructor</tt> is invalid outside of a subclass constructor.
<tt>super.constructor</tt> furthermore may only be called once per derived
constructor, and must be called before the derived constructor accesses
<tt>this</tt> or any instance variables.
</p>
<!-- ===================================================================== -->
<h3 id="expr-closure">Closure Expression</h3>
<!-- ===================================================================== -->
<pre class="grammar">
expr-closure ::= '{' closure-signature? <a href="#brace-item-list">brace-item-list</a> '}'
closure-signature ::= <a href="#pattern-tuple">pattern-tuple</a> <a href="#func-signature">func-signature-result</a>? 'in'
closure-signature ::= <a href="#identifier">identifier</a> (',' <a href="#identifier">identifier</a>*) <a href="#func-signature">func-signature-result</a>? 'in'
</pre>
<p>A closure defines an anonymous function as an expression. Like a
<a href="#decl-func">func</a> declaration, a closure has parameters,
a return type, and some number of statements that are executed when
the closure is called. Like local functions, closures can capture
values from its enclosing function and closure scopes. Closures are
often used in lieu of local functions when the function name would
only be used once, to be called by some other function. As a syntax
optimization, when the closure contains only a single expression, it's
value is used as the result of the closure. Thus, the closure <code>{
5 }</code> is equivalent to <code>{ return 5 }</code>.</p>
<p>Unlike <a href="#decl-func">func</a>
declarations, the return type, parameter types, and even the <a
href="#expr-anon-closure-arg">names of parameters</a> can be
omitted from the definition of the closure, making it a concise
syntax for small closures. In such cases, the context in which the
closure is used must provide information about the parameter and
return types. In the special case where the closure consists of only
a single expression, that expression participates in the
type checking of its context. </p>
<pre class="example">
<i>// Takes a closure that it calls to determine an ordering relation.</i>
func magic(val : Int, predicate : (a : Int, b : Int) -> Bool)
func f() {
<i>// Compare one way. Closure is inferred to return Bool and take two ints</i>
<i>// from the argument context. This same information infers that $0 and $1</i>
<i>// both have type 'Int'.</i>
magic(42, { $0 &lt; $1 })
<i>// Compare the other way way.</i>
magic(42, { $1 &lt; $0 })
<i>// Provide parameter names, but infer the types.</i>
magic(42, { x, y in y &lt; x })
<i>// Provide parameter names and types.</i>
magic(42, { (x : Int, y : Int) in y &lt; x })
<i>// Provide parameter names and types, and return type, with multiple statements.</i>
magic(42, { (x : Int, y : Int) -> Bool in
print("Comparing \(x) to \(y).\n")
return y &lt; x
})
<i>// Error, not enough context to infer the type of $0.</i>
var x = { $0 }
}
</pre>
<!-- ===================================================================== -->
<h3 id="expr-anon-closure-arg">Anonymous Closure Arguments</h3>
<!-- ===================================================================== -->
<pre class="grammar">
expr-anon-closure-arg ::= <a href="#dollarident">dollarident</a>
</pre>
<p>A use of an identifier whose name fits the "$[0-9]+" regular
expression is a reference to an anonymous closure argument that is formed when
the containing expression is <a href="#typecheck_anon">coerced into a closure
context</a>. All other dollar identifiers are invalid.</p>
<p>This can only be used in the body of a closure (<a
href="#expr-closure">expr-closure</a>) that does not have explicitly-specified parameters.
</p>
<!-- ===================================================================== -->
<h3 id="expr-delayed-identifier">Delayed Identifier Resolution</h3>
<!-- ===================================================================== -->
<div class="commentary">
The ".bar" syntax was picked because it is related to the syntax of a fully
qualified "foo.bar" reference.
</div>
<pre class="grammar">
expr-delayed-identifier ::= '.' <a href="#identifier">identifier</a>
</pre>
<p>A delayed identifier expression refers to a constructor of a <a
href="type-union">union</a> type, without knowing which type it is referring
to. The expression is resolved to a constructor of a concrete type through
context sensitive type inference.</p>
<pre class="example">
union Direction { case Up, Down }
func search(val : Int, direction : Direction)
func f() {
search(42, .Up)
search(17, .Down)
}
</pre>
<!-- ===================================================================== -->
<h3 id="expr-paren">Parenthesized Expressions</h3>
<!-- ===================================================================== -->
<pre class="grammar">
expr-paren ::= '(' ')'
expr-paren ::= '(' expr-paren-element (',' expr-paren-element)* ')'
expr-paren-element ::= (<a href="#identifier">identifier</a> ':')? <a href="#expr">expr</a>
</pre>
<p>Parentheses expressions contain an (optionally empty) list of optionally
named values. Parentheses in an expression context denote one of two
things: 1) grouping parentheses, or 2) a tuple literal.</p>
<p>Grouping parentheses occur when there is exactly one value in the list and
that value does not have a name. In this case, the type of the parenthesis
expression is the type of the single value.</p>
<p>All other cases are tuple literals. The type of the expression is a tuple
type whose elements and order match that of the initializer. If there are
any named elements, those elements become names for the tuple type. A
parenthesis expression with no value has a type of the empty tuple.
</p>
<p>Some examples:</p>
<pre class="example">
<i>// Simple grouping parenthesis.</i>
var a = (4) <i>// Type = Int</i>
var b = (4+a) <i>// Type = Int</i>
<i>// Tuple literals.</i>
var c = () <i>// Type = ()</i>
var d = (4, 5) <i>// Type = (Int, Int)</i>
var e = (c, d) <i>// Type = ((), (Int, Int))</i>
var f = (x : 4, y : 5) <i>// Type = (x : Int, y : Int)</i>
var g = (4, y : 5, 6) <i>// Type = (Int, y : Int, Int)</i>
<i>// Named arguments to functions.</i>
func foo(a : Int, b : Int)
foo(b = 4, a = 1)
</pre>
<!-- ===================================================================== -->
<h3 id="expr-dot">Dot Expressions</h3>
<!-- ===================================================================== -->
<pre class="grammar">
expr-dot ::= <a href="#expr">expr-postfix</a> '.' <a href="#dollarident">dollarident</a>
</pre>
<p>If the base expression has <a href="#type-tuple">tuple type</a>, then the
magic identifier "[0-9]+" accesses the specified anonymous member of the
tuple. Otherwise, this form is invalid.</p>
<pre class="grammar">
expr-dot ::= <a href="#expr">expr-postfix</a> '.' <a href="#expr-identifier">expr-identifier</a>
</pre>
<p>If the base expression has <a href="#type-tuple">tuple type</a> and if the
identifier is the name of a field in the tuple, then this is a reference to
the specified field.</p>
<p>Otherwise, <a href="#namebind_value_lookup_dot">dot name lookup</a> is
performed, and this expression is treated as function application. This
allows looking up members in modules, metatypes, etc.</p>
<!-- ===================================================================== -->
<h3 id="expr-subscript">Subscript Expressions</h3>
<!-- ===================================================================== -->
<div class="commentary">
There is no "built-in" semantics for subscripting. Rather, all
subscripting semantics is implemented via subscript declarations
in the library.
<br/>We require that the '[' not be the first token on a line, so that
a statement can begin with an array expression.
</div>
<pre class="grammar">
expr-subscript ::= <a href="#expr">expr-postfix</a> '[' <a href="#expr">expr</a> ']'
</pre>
<p>A subscript expression invokes a <a
href="#decl-subscript">subscript getter or setter</a> on the type
of the <tt>expr-postfix</tt>. The <tt>expr</tt> is used as the
subscript argument, which will be provided to either the getter or
setter depending on whether the subscript expression is used as an
rvalue (reading) or lvalue (writing), respectively. A subscript
expression that resolves to a subscript declaration with no setter
cannot be modified.</p>
<!-- ===================================================================== -->
<h3 id="expr-new">New Expressions</h3>
<!-- ===================================================================== -->
<div class="commentary">
It's not really clear what the behavior of multiple bounds should be.
<br/><br/>We should probably allow an initializer. The semantics would be
to evaluate that constructor for each element constructed.
</div>
<pre class="grammar">
expr-new ::= 'new' <a href="#type">type-identifier</a> expr-new-bounds
expr-new-bounds ::= expr-new-bound
expr-new-bounds ::= expr-new-bounds expr-new-bound
expr-new-bound ::= '[' <a href="#expr">expr?</a> ']'
</pre>
<p>Allocates and initializes a new array of objects. The first clause must
be an expression; subsequent bounds, if present, must be constant under
the <a href="#type-array">usual rules for array types</a>. The opening
square bracket must be on the same line as the type name.</p>
<!-- ===================================================================== -->
<h3 id="expr-call">Function Application</h3>
<!-- ===================================================================== -->
<pre class="grammar">
expr-call ::= <a href="#expr">expr-postfix</a> <a href="#expr-paren">expr-paren</a>
</pre>
<p>The leading <tt>'('</tt> of the <tt>expr-paren</tt> must not be
the first token on a line. This greatly reduces the likelihood of
confusion from semicolon elision, without requiring feedback from
the typechecker or more aggressive whitespace sensitivity.</p>
<p>If the <tt>expr-postfix</tt> refers to a (possibly
parenthesized) name of a type, the <tt>expr-paren</tt> is first
coerced to the type named by <tt>expr-postfix</tt>. If that coercion
fails, then the <tt>expr-postfix</tt> refers to the set of
constructors for that type.</p>
<p>Simple examples:</p>
<pre class="example">
<i>// Application of an empty tuple to the function f.</i>
f()
<i>// Application of 4 to the function f.</i>
g(4)
<i>// Application of 4 to the function returned by h().</i>
var h : (Int) -&gt; (Int) -&gt; Int
...
h()(4)
<i>// Two separate statements</i>
i()
(j &lt;+ 2)()
</pre>
<!-- ===================================================================== -->
<h3 id="expr-trailing-closure">Trailing Closures</h3>
<!-- ===================================================================== -->
<div class="commentary">
It is possible to model trailing closures as simply another way to
perform a function call, forgoing the syntactic transformation for
<a href="#expr-call">expr-call</a>, if functions meant to be used
with trailing closures are written as curried functions, e.g.,
<pre>
func map<T, U>(array : T[])(fn : (T) -> U) -> U[] { ... }
</pre>
There are two problems with this (admittedly simpler) design.
First, functions imported from C, C++, and Objective-C won't ever
be written in this curried syntax, so we would have to implement
redundant entry points to enable this syntax. Second, this design
forces the idea of currying front and center for Swift programmers
who otherwise wouldn't care, for mostly theoretical reasons.
</div>
<pre class="grammar">
expr-trailing-closure ::= <a href="#expr">expr-postfix</a> <a href="#expr-closure">expr-closure</a>+
</pre>
<p>A postfix expression followed by a closure will be invoked with
the closure as its argument. This syntax is referred to as a
"trailing" closure, because the closure itself is outside the
parentheses used to call the expression. Trailing closures are
syntactic sugar that eliminates the awkwardness of closing a
function call with "})", where the "}" ends the closure and the ")"
ends the call.</p>
<p>Trailing closures use a simple syntactic translation, making them
purely syntactic sugar. If the postfix expression preceding the
trailing closure is an <a href="#expr-call">expr-call</a>, the
closure is added to the end of the <a
href="#expr-paren">expr-paren</a> of that call. Otherwise, the
postfix expression is (implicitly) called with the trailing closure
as its only argument.</p>
<pre class="example">
dispatch_async(q) {
print("Whenever you get around to it\n")
}
</pre>
<!-- ********************************************************************* -->
<h2 id = "stmt">Statements</h2>
<!-- ********************************************************************* -->
<div class="commentary">
Statements can only exist in contexts that are themselves a stmt.
Statements have no type, they just induce control flow changes. We choose
to use constructs that will be familiar to a broad range of C/Java
programmers.
</div>
<pre class="grammar">
stmt ::= <a href="#stmt-semicolon">stmt-semicolon</a>
stmt ::= <a href="#stmt-if">stmt-if</a>
stmt ::= <a href="#stmt-while">stmt-while</a>
stmt ::= <a href="#stmt-for-c-style">stmt-for-c-style</a>
stmt ::= <a href="#stmt-for-each">stmt-for-each</a>
stmt ::= <a href="#stmt-switch">stmt-switch</a>
stmt ::= stmt-control-transfer
stmt-control-transfer ::= <a href="#stmt-return">stmt-return</a>
stmt-control-transfer ::= <a href="#stmt-break">stmt-break</a>
stmt-control-transfer ::= <a href="#stmt-continue">stmt-continue</a>
stmt-control-transfer ::= <a href="#stmt-fallthrough">stmt-fallthrough</a>
</pre>
<p>Statements provide the control flow constructs of function bodies and
top-level code.</p>
<pre class="example">
<i>// A function with some statements.</i>
func fib(v : Int) -&gt; Int {
if v &lt; 2 {
return v
}
return fib(v-1)+fib(v-2)
}
</pre>
<!-- ===================================================================== -->
<h3 id="stmt-semicolon">Semicolon Statement</h3>
<!-- ===================================================================== -->
<div class="commentary">
Allowing semicolons as statements causes us to allow semicolons as statement
separators as well. This, in turn, means that we don't reject code that has
semicolons after each statement, which will be common when people first
start getting used to Swift.
</div>
<pre class="grammar">
stmt-semicolon ::= ';'
</pre>
<p>The semicolon statement has no effect.</p>
<!-- ===================================================================== -->
<h3 id="stmt-return">'return' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-return ::= 'return' <a href="#expr">expr</a>
stmt-return ::= 'return'
</pre>
<p>The return statement sets the return value of the current <a
href="#decl-func">func declaration</a> or <a href="#expr-closure">closure
expression</a> and transfers control out of the function. It sets the
return value by converting the specified expression result (or '()' if
none is specified) to the return type of the 'func'.
</p>
<p>The stmt-return grammar is ambiguous: "{ return 4 }" could be parsed as
{"return" "4"} or as a single statement. Ambiguity here is resolved toward
the first production, because control flow can't transfer to an
subexpression.</p>
<!-- ===================================================================== -->
<h3 id="stmt-break">'break' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-return ::= 'break'
</pre>
<p>The 'break' statement transfers control out of the enclosing 'for' loop or
'while' loop.</p>
<!-- ===================================================================== -->
<h3 id="stmt-continue">'continue' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-return ::= 'continue'
</pre>
<p>The 'continue' statement transfers control back to the start of the
enclosing 'for' loop or 'while' loop.</p>
<!-- ===================================================================== -->
<h3 id="stmt-if">'if' Statement</h3>
<!-- ===================================================================== -->
<div class="commentary">
We require braces around the body of an 'if' for two reasons: first, it
eliminates the need for parentheses around the condition by making them
visually distinctive. Second, it will eliminate all the dithering about
whether and when people should, or should not, use braces for if bodies.
</div>
<pre class="grammar">
stmt-if ::= 'if' <a href="#expr">expr-basic</a> <a href="#brace-item-list">brace-item-list</a> stmt-if-else?
stmt-if-else ::= 'else' <a href="#brace-item-list">brace-item-list</a>
stmt-if-else ::= 'else' stmt-if
</pre>
<p>'if' statements provide a simple control transfer operations that evaluates
the condition, invokes the 'getLogicValue' member of the result if the result
not a 'Bool', then determines the direction of the branch based on the result.
(Internally, the standard library type 'Bool' has a getLogicValue member that
returns a 'Builtin.Int1'.) It is an error if the type of the expression is
context-dependent or some non-Bool type.
</p>
<p>Some examples include:</p>
<pre class="example">
if true {
/*...*/
}
if X == 4 {
} else {
}
if X == 4 {
} else if X == 5 {
} else {
}
</pre>
<!-- ===================================================================== -->
<h3 id="stmt-while">'while' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-while ::= 'while' <a href="#expr">expr-basic</a> <a href="#brace-item-list">brace-item-list</a>
</pre>
<p>'while' statements provide simple loop construct which (on each iteration
of the loop) evalutes the condition, invokes the 'getLogicValue' member of
the result if the result not a 'Bool', then determines whether to keep
looping. (Internally, the standard library type 'Bool' has a getLogicValue
member that returns a 'Builtin.Int1'.) It is an error if the type of
the expression is context-dependent or some non-Bool type.
</p>
<p>Some examples include:</p>
<pre class="example">
while true {
/*...*/
}
while X == 4 {
X = 3
}
</pre>
<!-- ===================================================================== -->
<h3 id="stmt-do-while">'do-while' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-do-while ::= 'do' <a href="#brace-item-list">brace-item-list</a> 'while' '<a href="#expr">expr</a>
</pre>
<p>'do-while' statements provide simple loop construct which (on each
iteration of the loop) evaluates the body, then evaluates the condition,
invoking the 'getLogicValue' member of the result if the result not a 'Bool',
then determines whether to keep looping. (Internally, the standard library
type 'Bool' has a getLogicValue member that returns a 'Builtin.Int1'). It is
an error if the type of the expression is context-dependent or some non-Bool
type.
</p>
<p>Some examples include:</p>
<pre class="example">
do {
/*...*/
} while true
do {
X = 3
} while X == 4
</pre>
<!-- ===================================================================== -->
<h3 id="stmt-for-c-style">C-Style 'for' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-for-c-style ::= 'for' stmt-for-c-style-init? ';' <a href="#expr">expr</a>? ';' expr-basic? <a href="#brace-item-list">brace-item-list</a>
stmt-for-c-style ::= 'for' '(' stmt-for-c-style-init? ';' <a href="#expr">expr</a>? ';' expr-basic? ')' <a href="#brace-item-list">brace-item-list</a>
stmt-for-c-style-init ::= <a href="#decl-var">decl-var</a>
stmt-for-c-style-init ::= expr
</pre>
<p>C-Style 'for' statements provide simple loop construct which evaluates the
first part (the initializer) before entering the loop, then evalutes the
second condition as a logic value to determines whether to keep looping.
The third condition is executed at the end of the loop. All three are
evaluated in a new scope that surrounds the for statement.
</p>
<p>Some examples include:</p>
<pre class="example">
for i = 0; i != 10; ++i {
/*...*/
}
for (i = 0; i != 10; ++i) {
/*...*/
}
for var (i,j) = (0,1); i != 10; ++i {
/*...*/
}
</pre>
<!-- ===================================================================== -->
<h3 id="stmt-for-each">'for-each' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-for-each ::= 'for' <a href="#pattern">pattern</a> 'in' <a href="#expr">expr-basic</a> <a href="#brace-item-list">brace-item-list</a>
</pre>
<p>Enumerator-based 'for' statements provide enumeration over the values in a
container. The <tt>expr</tt> is either a container or an enumerator; and
respectively, it either conforms to the formal Enumeration or formal Enumerator
protocol.
<p>Note that each iteration of the loop declares a distinct variable for each
variable in the pattern. For example, in a loop like "for i in 0..10",
if i is captured inside the loop, each iteration captures a different "i",
so there would be a total of ten versions generated each time the loop
runs.</p>
<p>Some examples include:</p>
<pre class="example">
for i in 0..100 {
println(String(i));
}
</pre>
<!-- ===================================================================== -->
<h3 id="stmt-switch">'switch' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-switch ::= 'switch' <a href="#expr">expr-basic</a> '{' stmt-switch-case* '}'
stmt-switch-case ::= (case-label+ | default-label) <a href="#brace-item-list">brace-item</a>*
case-label ::= 'case' <a href="#pattern">pattern</a> (',' pattern)* ('where' expr)? ':'
default-label ::= 'default' ':'
</pre>
<p>'switch' statements branch on the value of an expression by
<a href="#pattern">pattern matching</a>.
The subject expression of the switch is evaluated and tested against the
patterns in its <tt>case</tt> labels in source order. When a pattern is
found that matches the value, control is transferred into the matching
<tt>case</tt> block. <tt>case</tt> labels may declare multiple patterns
separated by commas, and multiple <tt>case</tt> labels may cover a
case block. Case labels may optionally specify a <i>guard</i> expression,
introduced by the <tt>where</tt> keyword; if present, control is
transferred to the case only if the subject value both matches one of its
patterns and the guard expression evaluates to true. Patterns are tested
"as if" in source order; if multiple cases can match a value, control is
transferred only to the first matching case. The actual execution order
of pattern matching operations, and in particular the evaluation order of
<a href="#pattern-expr">expression patterns</a>, is unspecified.</p>
<p>A switch may also contain a <tt>default</tt> block. If present, it
receives control if no cases match the subject value. The <tt>default</tt>
block must appear at the end of the switch and must be the only label for
its block. (<tt>default</tt> is equivalent to a final <tt>case _</tt>
pattern.) Switches are required to be exhaustive; either the contained case
patterns must cover every possible value of the subject's type, or else
an explicit <tt>default</tt> block must be specified to handle uncovered
cases.</p>
<p>Every case and default block has its own
scope. Declarations within a case or default block are only visible within
that block. Case patterns may bind variables using the
<a href="#pattern-var"><tt>var</tt> keyword</a>; those variables are also
scoped into the corresponding case block, and may be referenced in the
<tt>where</tt> guard for the case label. However, if a case block matches
multiple patterns, none of those patterns may contain variable bindings.</p>
<p>Control does not implicitly 'fall through' from one case block to
the next. <a href="#stmt-fallthrough"><tt>fallthrough</tt> statements</a>
may explicitly transfer control among case blocks.
<a href="#stmt-break"><tt>break</tt></a> and
<a href="#stmt-continue"><tt>continue</tt></a>
within a switch will break or continue out of an enclosing 'while' or
'for' loop, not out of the 'switch' itself.</p>
<pre class="example">
func classifyPoint(point:(Int, Int)) {
switch point {
case (0, 0):
println("origin")
case (_, 0):
println("on the x axis")
case (0, _):
println("on the y axis")
case (var x, var y) where x == y:
println("on the y = x diagonal")
case (var x, var y) where -x == y:
println("on the y = -x diagonal")
case (var x, var y):
println("length \(sqrt(x*x + y*y))")
}
}
</pre>
<!-- ===================================================================== -->
<h3 id="stmt-fallthrough">'fallthrough' Statement</h3>
<!-- ===================================================================== -->
<pre class="grammar">
stmt-fallthrough ::= 'fallthrough'
</pre>
<p><tt>fallthrough</tt> transfers control from a <tt>case</tt> block of a
<a href="#stmt-switch"><tt>switch</tt> statement</a> to the next
<tt>case</tt> or <tt>default</tt> block within the switch. It may only
appear inside a <tt>switch</tt>. <tt>fallthrough</tt> cannot be used in
the final block of a <tt>switch</tt>. It also cannot transfer control into
a <tt>case</tt> block whose pattern contains
<a href="#pattern-var"><tt>var</tt> bindings</a>.</p>
<!-- ********************************************************************* -->
<h2>Protocols</h2>
<!-- ********************************************************************* -->
<!-- ********************************************************************* -->
<h2>Objects</h2>
<!-- ********************************************************************* -->
<!-- ********************************************************************* -->
<h2>Generics</h2>
<!-- ********************************************************************* -->
<!-- ********************************************************************* -->
<h2 id="namebind">Name Binding</h2>
<!-- ********************************************************************* -->
<p>Name binding in swift is performed in different ways depending on what
language entity is being considered:</p>
<p>Value names (for <a
href="#decl-var">var</a> and <a href="#decl-func">func</a> declarations) and
type names (for <a href="#decl-typealias">typealias</a>, <a
href="#decl-union">union</a>, and <a href="#decl-struct">struct</a>
declarations) follow the same <a href="#namebind_scope">scope</a> and
<a href="#namebind_typevalue_lookup">name lookup</a> rules as described below.
</p>
<p>tuple element names</p>
<p>scope within union decls</p>
<p>Context sensitive member references are resolved <a
href="#typecheck_context">during type checking</a>.</p>
<h3 id="namebind_scope">Scopes for Type and Value Names</h3>
<h3 id="namebind_value_lookup_unqual">Name Lookup Unqualified Value Names</h3>
<h3 id="namebind_value_lookup_dot">"dot" Name Lookup Value Names</h3>
<h3 id="namebind_typevalue_lookup">Name Lookup for Type and Value Names</h3>
<p>Basic algo:</p>
<ul>
<li>Search the current scope tree for a local name. Local names cannot be
forward referenced.</li>
<li>Bind to names defined in the current component, including the current
translation unit. TODO: is this a good thing? We could require explicit
imports if we wanted to.</li>
<li>Bind to identifiers that are imported with an import directive. Imports
are searched in order of introduction (top-down). The location of an
import directive in a file (e.g. between func decls) does not affect name
lookup, but the order of imports w.r.t. each other does.</li>
</ul>
<p>Shadowing: Given a ValueDecl D1 in the current module and a ValueDecl D2
in an imported module with the same name and a member of the same type (if
relevant): 1. If D1 is a TypeDecl, D2 is shadowed. 2. If neither D1 nor D2
is a TypeDecl, and they have the same type, D2 is shadowed. If a
declaration in an imported module is shadowed by any declaration in the
current module, it is not found by unqualified global lookup or lookup for
members of a type.</p>
<h3 id="namebind_dot">Name Lookup for Dot Expressions</h3>
<p>
<a href="#expr-dot">Dot Expressions</a> bind to name of tuple elements.
</p>
<!-- ********************************************************************* -->
<h2 id="typecheck">Type Checking</h2>
<!-- ********************************************************************* -->
<p>
Binary expressions, function application, etc.
</p>
<h3 id="typecheck_conversions">Standard Conversions</h3>
<!--
Consider foo(4, 5) when foo is declared to take ((Int,Int=3), Int=6). This
could be parsed as either ((4,5), 6) or ((4,3),5), but the later one is
the "right" answer.
-->
<h3 id="typecheck_anon">Anonymous Argument Resolution</h3>
<h3 id="typecheck_context">Context Sensitive Type Resolution</h3>
<!-- ********************************************************************* -->
<h2 id="stdlib">Standard Library</h2>
<!-- ********************************************************************* -->
<div class="commentary">
It would be really great to have literate swift code someday, that way
this could be generated directly from the code. This would also be powerful
for Swift library developers to be able to depend on being available and
standardized.
</div>
<p>This describes some of the standard swift code as it is being built up.
Since Swift is designed to give power to the library developers, much of
what is normally considered the "language" is actually just implemented in
the library.</p>
<p>All of this code is published by the 'swift' module, which is
implicitly imported into each translation unit, unless some sort of pragma
in the code (attribute on an import?) is used to change or disable this
behavior.</p>
<!-- ===================================================================== -->
<h3 id="builtin">Builtin Module</h3>
<!-- ===================================================================== -->
<p>In the initial Swift implementation, a module named <tt>Builtin</tt> is
imported into every file. Its declarations can only be found by <a
href="#expr-dot">dot syntax</a>. It provides access to a small
number of primitive representation types and operations defined over them
that map directly to LLVM IR.</p>
<p>The existance of and details of this module are a private implementation
detail used by our implementation of the standard library. Swift code
outside the standard library should not be aware of this library, and an
independent implementation of the swift standard library should be
allowed to be implemented without the builtin library if it desires.</p>
<p>For reference below, the description of the standard library uses the
"Builtin." namespace to refer to this module, but independent
implementations could use another implementation if they so desire.</p>
<!-- ===================================================================== -->
<h3 id="stdlib-simple-types">Simple Types</h3>
<!-- ===================================================================== -->
<h4 id="stdlib-Void">Void</h4>
<pre class="stdlib">
<i>// Void is just a type alias for the empty tuple.</i>
typealias Void = ()
</pre>
<div class="commentary">
Having a single standardized integer type that can be used by default
everywhere is important. One advantage Swift has is that by the time it is
in widespread use, 64-bit architectures will be pervasive, and the LLVM
optimizer should grow to be good at shrinking 64-bit integers to 32-bit in
many cases for those 32-bit architectures that persist.
</div>
<h4 id="stdlib-Int">Int, Int8, Int16, Int32, Int64</h4>
<pre class="stdlib">
<i>// Fixed size types are simple structs of the right size.</i>
struct Int8 { value : Builtin.Int8 }
struct Int16 { value : Builtin.Int16 }
struct Int32 { value : Builtin.Int32 }
struct Int64 { value : Builtin.Int64 }
struct Int128 { value : Builtin.Int128 }
<i>// Int is just an alias for the 64-bit integer type.</i>
typealias Int = Int64
</pre>
<h4 id="stdlib-Int">Int, Int8, Int16, Int32, Int64</h4>
<pre class="stdlib">
struct Float { value : Builtin.FPIEEE32 }
struct Double { value : Builtin.FPIEEE64 }
</pre>
<h4 id="stdlib-Bool">Bool, true, false</h4>
<pre class="stdlib">
<i>// Bool is a simple discriminated union.</i>
union Bool {
true, false
}
<i>// Allow true and false to be used unqualified.</i>
var true = Bool.true
var false = Bool.false
</pre>
<!-- ===================================================================== -->
<h3 id="stdlib-arithmetic">Arithmetic and Logical Operations</h3>
<!-- ===================================================================== -->
<div class="commentary">
This is all eagerly awaiting the day when we have generics and overloading.
For now, Int is the only arithmetic type :)
</div>
<h4 id="stdlib-arithmetic">Arithmetic Operators</h4>
<pre class="stdlib">
<i>// Simple binary operators, following the same precedence as C.</i>
func [infix_left=200] * (lhs: Int, rhs: Int) -&gt; Int
func [infix_left=200] / (lhs: Int, rhs: Int) -&gt; Int
func [infix_left=200] % (lhs: Int, rhs: Int) -&gt; Int
func [infix_left=190] + (lhs: Int, rhs: Int) -&gt; Int
func [infix_left=190] - (lhs: Int, rhs: Int) -&gt; Int
<i>// In C, &lt;&lt;, &gt;&gt; is 180.</i>
</pre>
<h4 id="stdlib-comparison">Relational and Equality Operators</h4>
<pre class="stdlib">
func [infix_left=170] &lt; : (lhs : Int, rhs : Int) -&gt; Bool
func [infix_left=170] &gt; : (lhs : Int, rhs : Int) -&gt; Bool
func [infix_left=170] &lt;= : (lhs : Int, rhs : Int) -&gt; Bool
func [infix_left=170] &gt;= : (lhs : Int, rhs : Int) -&gt; Bool
func [infix_left=160] == : (lhs : Int, rhs : Int) -&gt; Bool
func [infix_left=160] != : (lhs : Int, rhs : Int) -&gt; Bool
<i>// In C, bitwise logical operators are 130,140,150.</i>
</pre>
<h4 id="stdlib-short-circuit-logical">Short Circuiting Logical Operators</h4>
<pre class="stdlib">
func [infix_left=120] &amp;&amp; (lhs: Bool, rhs: ()-&gt;Bool) -&gt; Bool
func [infix_left=110] || (lhs: Bool, rhs: ()-&gt;Bool) -&gt; Bool
<i>// In C, 100 is ?:</i>
<i>// In C, 90 is =, *=, += etc.</i>
</pre>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
</address>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink