This allows expressions such as ".foo" and ".foo(1)" to refer to
static variables and static methods, respectively, as well as enum
cases.
To get here, rework the parsing of delayed identifier expressions a
bit, so that the argument itself is part of the delayed argument
expression rather than a separate call expression. This simplifies
both the handling of patterns of this form and the type checker, which
can now user simpler constraints.
If we really want to support (.foo)(1), we can make that work, but it
seems unnecessary and perhaps confusing.
Swift SVN r10626
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
There are still some [infix_left=] in the text. Based on
r4627 it looks like these can just be deleted, but I haven't
done so at this time.
Swift SVN r9616
Also, improve error recovery for new-syntax attributes.
This means that we now compile the testcase into:
t.swift:3:16: error: unknown attribute 'xyz'
var x : () -> @xyz Int
^
t.swift:6:16: error: unknown attribute 'xyz'
func foo() -> @xyz Int {
^
instead of:
t.swift:4:15: error: expected type for function result
func foo() -> @xyz Int {
^
t.swift:4:14: error: consecutive statements on a line must be separated by ';'
func foo() -> @xyz Int {
^
;
t.swift:4:16: error: unknown attribute 'xyz'
func foo() -> @xyz Int {
^
t.swift:7:1: error: expected declaration
^
this is part of rdar://15183765
Swift SVN r9260
Now that we have a solid Optional-based story for dynamic casts, it's no longer needed, and can be expressed as '(x as T)!'. Future refinement of the 'as' syntax will deal with the unfortunate extra parens.
Swift SVN r9181
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
