As with the monadic '?', we treat any left-bound '!' as a postfix
operator. Currently, it extracts the value of its optional
subexpression, failing at run-time if the optional is empty.
Swift SVN r8948
Require that either T be default constructible or that the user provide a closure that maps indices to initial values. We don't actually call the closure yet to initialize the array; that's blocked on function abstraction difference <rdar://problem/13251236>.
Swift SVN r8801
For consistency with our other decl types. There aren't any case-specific attributes yet, but if/when we add them, this is where they'll go.
Swift SVN r8779
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
Implement the new rules for mapping between selector names and
constructors. The selector for a given constructor is formed by
looking at the names of the constructor parameters:
* For the first parameter, prepend "init" to the parameter name and
uppercase the first letter of the parameter name. Append ':' if
there are > 1 parameters or the parameter has non-empty-tuple type.
* For the remaining parameters, the name of each parameter followed
by ':'.
When a parameter doesn't exist, assume that the parameter name is the
empty string.
And, because I failed to commit it separately, support selector-style
declarations of constructor parameters so that we can actually write
constructors nicely, e.g.:
// selector is initWithFoo:bar:
constructor withFoo(foo : Foo) bar(bar : Bar) { ... }
Swift SVN r8361
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
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
This is particularly convenient for dealing with generated
code (e.g. as produced by the SIL printer), but it's also
quite defensible as a way for users to logically group
related attributes and split unrelated ones out, should
users find themselves using a lot of verbose attributes
(and prior experience with e.g. user-defined attributes
is that they definitely do sometimes turn into walls of
text...).
Swift SVN r7376
This documents the current state of affairs, where "Int?[]" is allowed but
"Int[]?" is not. I'll update this again if/when we reach a new decision.
Swift SVN r7269
We never really discussed this and it doesn't really buy us much. If we
want to have a compact way to import many things, it may not even end
up looking like this.
Swift SVN r7015
Also, update LangRef.
Note that an explicit "import module" has been left out for now, since
it's not strictly necessary and "module" isn't a keyword yet.
Swift SVN r6786
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
Standardize on the more-common "superclass" and "subclass" terminology
throughout the compiler, rather than the odd mix of base/derived and
super/sub.
Also, have ClassDecl only store the Type of the superclass. Location
information will be part of the inheritance clause for parsed classes.
Swift SVN r6687
This makes long literals like 1_000_000_000 or 0x7FFF_FFFF_FFFF_FFFF much easier to read, and has precedent in Perl, OCaml, Python, Ruby, Rust, ... Fixes <rdar://problem/14247571>.
Swift SVN r6681
Re-alphabetize 'where' among the declaration keywords. Eliminate the now non-user-facing "identifier-like keyword" concept and sort them among the other expression keywords. Add 'in' as a keyword.
Swift SVN r6182
Per r6154, this is now dead code. The only places we allow default
arguments will be visited by normal type validation, so there's
nothing specific to do here.
Swift SVN r6157
Per previous discussions, we only want to allow default values for
uncurried 'func' and 'constructor' parameters, and not for return
types or arbitrary tuple types. Introduce this restriction, fixing
part of <rdar://problem/13372694>.
Swift SVN r6156
In this syntax, the closure signature (when present) is placed within
the braces and the 'in' keyword separates it from the body of the
closure, e.g.,
magic(42, { (x : Int, y : Int) -> Bool in
print("Comparing \(x) to \(y).\n")
return y < x
})
When types are omitted from the parameter list, one can also drop the
parentheses, e.g.,
magic(42, { x, y -> Bool in
print("Comparing \(x) to \(y).\n")
return y < x
})
The parsing is inefficient and recovers poorly (in part because 'in'
is a contextual keyword rather than a real keyword), but it should
handle the full grammar. A number of tests, along with the whitepaper
and related rational documents, still need to be updated. Still, this
is the core of <rdar://problem/14004323>.
Swift SVN r6105
