Ballerina Language Specification, 2019R3

The language described in this specification is now stable, with the exception of features that are explicitly marked as having Preview status. We expect the final design of these features to be close enough to the current design that it will be straightforward for code that makes uses the current design to be updated to the final design.

The specification of features that have not yet reached preview status has been moved into a separate document.

5. Values, types and variables

Ballerina programs operate on a rich universe of values. This universe of values is partitioned into a number of basic types; every value belongs to exactly one basic type.

Values are of three kinds, each corresponding to a kind of basic type:

simple values, like booleans and floating point numbers, which are not constructed from other values;
structured values, like mappings and lists, which create structures from other values;
behavioral values, like functions, which allow parts of Ballerina programs to be handled in a uniform way with other values

Values can be stored in variables or as members of structures. A simple value is stored directly in the variable or structure. However, for other types of value, what is stored in the variable or member is a reference to the value; the value itself has its own separate storage. Non-simple types (i.e. structured types and behavioral types) are thus collectively called reference types. A reference value has an identity determined by its storage location. References make it possible for distinct members of a structure to refer to values that are identical, in the sense that they are stored in the same location. Thus values in Ballerina represent not just trees but graphs.

Simple values are inherently immutable because they have no identity distinct from their value. All basic types of structural values, with the exception of XML, are mutable, meaning the value referred to by a particular reference can be changed. Whether a behavioral value is mutable depends on its basic type: some of the behavioral basic types allow mutation, and some do not. Mutation cannot change the basic type of a value. Mutation makes it possible for the graphs of references between values to have cycles.

Ballerina programs use types to categorize values both at compile-time and runtime. Types deal with an abstraction of values, which does not consider storage location or mutability. This abstraction is called a shape. A type denotes a set of shapes. Subtyping in Ballerina is semantic: a type S is a subtype of type T if the set of shapes denoted by S is a subset of the set of shapes denoted by T. Every value has a corresponding shape. A shape is specific to a basic type: if two values have different basic types, then they have different shapes. Since shapes do not deal with storage location, they have no concept of identity; shapes therefore represent trees rather graphs. For simple values, there is no difference between a shape and a value, with the exception of floating point values where the shape does not consider representation details that do not affect the mathematical value being represented. There are two important relations between a value and a type:

a value looks like a type at a particular point in the execution of a program if its shape at that point is a member of the type;
a value belongs to a type if it looks like the type, and it will necessarily continue to look like the type no matter how the value is mutated.

For an immutable value, looking like a type and belonging to a type are the same thing.

When a Ballerina program declares a variable to have a compile-time type, this means that the Ballerina compiler together with the runtime system will ensure that the variable will only ever contain a value that belongs to the type. Ballerina also provides mechanisms that take a value that looks like a type and use it to create a value that belongs to a type.

type-descriptor :=
   simple-type-descriptor
   | structured-type-descriptor
   | behavioral-type-descriptor
   | other-type-descriptor

Ballerina provides a rich variety of type descriptors, which programs use to describe types. For example, there is a type descriptor for each simple basic type; there is a type descriptor that describes as type as a union of two types; there is a type descriptor that uses a single value to describe a type that contains a single shape. This means that values can look like and belong to arbitrarily many types, even though they look like or belong to exactly one basic type.

The following table summarizes the type descriptors provided by Ballerina.

Kind	Name	Set of values denoted by type descriptor
basic, simple	nil	()
	boolean	true, false
	int	64-bit signed integers
	float	64-bit IEEE 754-2008 binary floating point numbers
	decimal	decimal floating point numbers
	string	sequences of Unicode scalar values
basic, structured	array	an ordered list of values, optionally with a specific length, where a single type is specified for all members of the list,
	tuple	an ordered list of values, where a type is specified separately for each member of the list
	map	a mapping from keys, which are strings, to values; specifies mappings in terms of a single type to which all keys are mapped
	record	a mapping from keys, which are strings, to values; specifies maps in terms of names of fields (required keys) and value for each field
	table	a two-dimesional collection of immutable values
	XML	a sequence of zero or more characters, XML elements, processing instructions or comments
	error	an indication that there has been an error, with a string identifying the reason for the error, and a mapping giving additional details about the error
basic, behavioral	function	a function with 0 or more specified parameter types and a single return type
	future	a value to be returned by a function execution
	object	a combination of named fields and named methods
	service	a collection of named methods, including resource methods
	typedesc	a type descriptor
	handle	reference to externally managed storage
other	singleton	a single value described by a literal
	union	the union of the component types
	optional	the underlying type and ()
	any	any value other than an error
	anydata	not an error and does not contain behavioral members at any depth
	byte	int in the range 0 to 255 inclusive
	json	the union of (), int, float, decimal, string, and maps and arrays whose values are, recursively, json

In addition to describing a type, a type descriptor may also include information used to construct a value of the type, as well as metadata. Whereas the type described by a type descriptor is known at compile time, this additional information may need to be resolved at runtime. The typedesc basic type represents a type descriptor that has been resolved.

Most basic types of structured values (along with one basic type of simple value) are iterable, meaning that a value of the type can be accessed as a sequence of simpler values.

5.1 Simple values

A simple value belongs to exactly one of the following basic types:

nil
boolean
int
float
decimal
string

The type descriptor for each simple basic type contains all the values of the basic type.

simple-type-descriptor :=
   nil-type-descriptor
   | boolean-type-descriptor
   | int-type-descriptor
   | floating-point-type-descriptor
   | string-type-descriptor

5.1.1 Nil

nil-type-descriptor :=  ( )
nil-literal :=  ( ) | null

The nil type contains a single value, called nil, which is used to represent the absence of any other value. The nil value is written (). The nil value can also be written null, for compatibility with JSON; the use of null should be restricted to JSON-related contexts.

The nil type is special, in that it is the only basic type that consists of a single value. The type descriptor for the nil type is not written using a keyword, but is instead written () like the value.

5.1.2 Boolean

boolean-type-descriptor := boolean
boolean-literal := true | false

The boolean type consists of the values true and false.

5.1.3 Int

int-type-descriptor := int
int-literal := DecimalNumber | HexIntLiteral
DecimalNumber := 0 | NonZeroDigit Digit*
HexIntLiteral := HexIndicator HexNumber
HexNumber := HexDigit+
HexIndicator := 0x | 0X
HexDigit := Digit | a .. f | A .. F
NonZeroDigit := 1 .. 9

The int type consists of integers between -9,223,372,036,854,775,808 and 9,223,372,036,854,775,807 (i.e. signed integers than can fit into 64 bits using a two's complement representation)

5.1.4 Floating point types

floating-point-type-descriptor := float | decimal
floating-point-literal :=
   DecimalFloatingPointNumber | HexFloatingPointLiteral
DecimalFloatingPointNumber :=
   DecimalNumber Exponent [FloatingPointTypeSuffix]
   | DottedDecimalNumber [Exponent] [FloatingPointTypeSuffix]
   | DecimalNumber FloatingPointTypeSuffix
DottedDecimalNumber :=
   DecimalNumber . Digit*
   | . Digit+
Exponent := ExponentIndicator [Sign] Digit+
ExponentIndicator := e | E
HexFloatingPointLiteral := HexIndicator HexFloatingPointNumber
HexFloatingPointNumber :=
   HexNumber HexExponent
   | DottedHexNumber [HexExponent]
DottedHexNumber :=
   HexDigit+ . HexDigit*
   | . HexDigit+
HexExponent := HexExponentIndicator [Sign] Digit+
HexExponentIndicator := p | P
Sign := + | -
FloatingPointTypeSuffix := DecimalTypeSuffix | FloatTypeSuffix
DecimalTypeSuffix := d | D
FloatTypeSuffix :=  f | F

5.1.4.1 Float

The float type corresponds to IEEE 754-2008 64-bit binary (radix 2) floating point numbers. A float value can be represented by either a DecimalFloatingPointNumber with an optional FloatTypeSuffix, or by a HexFloatingPointLiteral.

The multiple bit patterns that IEEE 754 treats as NaN are considered to be the same value in Ballerina. Positive and negative zero of a floating point basic type are distinct values, following IEEE 754, but are defined to have the same shape, so that they will usually be treated as being equal.

IEEE-defined operations on float values must be performed using a rounding-direction attribute of roundTiesToEven (which is the default IEEE rounding direction, sometimes called round to nearest). All float values, including the intermediate results of expressions, must use the value space defined for the float type; implementations must not use extended precision for intermediate results. This ensures that all implementations will produce identical results. (This is the same as what is required by strictfp in Java.)

5.1.4.2 Decimal

The decimal type corresponds to a subset of IEEE 754-2008 128-bit decimal (radix 10) floating point numbers. Any decimal value can be represented by a DecimalFloatingPointNumber with an optional DecimalTypeSuffix.

A decimal value is a triple (s, c, e) where

s is sign, either 0 or -1
c is the coefficient, an unsigned integer that can be exactly represented in 34 decimal digits
e is the exponent, a signed integer

representing the mathematical value -1^s × c × 10^e. The range for the exponent e is implementation dependent, but must be at least the range supported by the IEEE 754-2008 decimal128 format (which is -6176 to 6111 inclusive).

The decimal type corresponds to the ANSI X3.X274 subset of IEEE 754-2008, which has the following simplifications:

+0 and -0 are not distinguished; if the coefficent is zero, then the sign is also constrained to be zero;
NaN, infinities and subnormals are not supported; operations that would result in one of these values according to the normal rules of IEEE 754-2008 instead result in a panic.

Operations on the decimal type use the roundTiesToEven rounding mode, like the float type.

The shape of a decimal value is its mathematical value. Thus two decimal values have the same shape if they represent the same mathematical value, even if they do so using different exponents.

5.1.5 Strings

string-type-descriptor := string
string-literal := DoubleQuotedStringLiteral
DoubleQuotedStringLiteral := " (StringChar | StringEscape)* "
StringChar := ^ ( 0xA | 0xD | \ | " )
StringEscape := StringSingleEscape | StringNumericEscape
StringSingleEscape := \t | \n | \r | \\ | \"
StringNumericEscape := \u[ CodePoint ]
CodePoint := HexDigit+

A string is an immutable sequence of zero or more Unicode scalar values, where a Unicode scalar value is any code point in the Unicode range of 0x0 to 0x10FFFF inclusive, other than surrogate code points, which are 0xD800 to 0xDFFF inclusive. Note that a string may include Unicode noncharacters, such as 0xFFFE and 0xFFFF.

In a StringNumericEscape, CodePoint must valid Unicode code point; more precisely, it must be a hexadecimal numeral denoting an integer n where 0 <= n < 0xD800 or 0xDFFF < n <= 0x10FFFF.

A string is iterable as a sequence of its single code point substrings. String is the only simple type that is iterable.

5.2 Structured values

There are five basic types of structured value. First, there are two container basic types: list and mapping. Second, there are the table, xml and error basic types, which are each special in different ways.

A structured value is either mutable or immutable; whether it is mutable or immutable is fixed when the value is constructed and cannot be changed thereafter. Immutability is deep: an immutable structured value cannot refer to a mutable structured value. The error basic type is inherently immutable: a value of the error basic type is always immutable. Structured values of other basic types are usually mutable, but can be constructed as immutable in two ways. First, a structural value constructed by a compile-time constant expression is always immutable. Second, an immutable, deep copy can be made of a structure by using the ImmutableClone abstract operation.

Values of the container basic types are containers for other values, which are called their members. The shape of the members of a container value contribute to the shape of the container. Mutating a member of a container can thus cause the shape of the container to change.

A type descriptor for a container basic type describe the shape of the container in terms of the shapes of its members. A container has an inherent type, which is a type descriptor which is part of the container's runtime value. At runtime, the container prevents any mutation that might lead to the container having a shape that is not a member of its inherent type. Thus a container value belongs to a type if and only if that its inherent type is a subtype of that type.

The inherent type of an immutable container is a singleton type with the container's shape as its single member. Thus, an immutable container value belongs to a type if and only if the type contains the shape of the value.

Each member of a container has a key that uniquely identifies it within the container. The member type for a key type K in a container type T consists of all shapes v such that there is a shape in T with key in K and shape v. A type K is an optional key type for T if there is a shape v in T and a key k in K such that v does not have a member k; a type that is not an optional key type is a required key type.

structured-type-descriptor :=
   list-type-descriptor
   | mapping-type-descriptor
   | table-type-descriptor
   | xml-type-descriptor
   | error-type-descriptor

The following table summarizes the type descriptors for structured types.

	Integer key	String key
Basic type	list	mapping
Type descriptor with uniform member type	array	map
Type descriptor with separate member types	tuple	record

A value is defined to be pure if it either

is a simple value, or
is a structured value, all of whose members are also pure values.

A shape is pure if it is the shape of a pure value. A type is pure if it contains only pure shapes.

5.2.1 Lists

A list value is a container that keeps its members in an ordered list. The number of members of the list is called the length of the list. The key for a member of a list is the integer index representing its position in the list, with the index of the first member being 0. For a list of length n, the indices of the members of the list, from first to last, are 0,1,...,n - 1. The shape of a list value is an ordered list of the shapes of its members.

A list is iterable as a sequence of its members.

The type of list values can be described by two kinds of type descriptors.

list-type-descriptor :=
   array-type-descriptor | tuple-type-descriptor

The inherent type of a list value must be a list-type-descriptor. The inherent type of a list value determines a type T_i for a member with index i. The runtime system will enforce a constraint that a value written to index i will belong to type T_i. Note that the constraint is not merely that the value looks like T_i.

Both kinds of type descriptor are covariant in the types of their members.

5.2.1.1 Array types

An array type-descriptor describes a type of list value by specifying the type that the value for all members must belong to, and optionally, a length.

array-type-descriptor := member-type-descriptor [ [ array-length ] ]
member-type-descriptor := type-descriptor
array-length :=
   int-literal
   | constant-reference-expr
   | inferred-array-length
inferred-array-length := *

A type T[] contains a list shape if all members of the list shape are in T. A type T[n] contains a list shape if in addition the length of the list shape is n.

A constant-reference-expr in an array-length must evaluate to a non-negative integer. An array length of * means that the length of the array is to be inferred from the context; this is allowed only within a type descriptor occurring in a context that is specified to be inferable; its meaning is the same as if the length was specified explicitly.

Note also that T[n] is a subtype of T[], and that if S is a subtype of T, then S[] is a subtype of T[]; this is a consequence of the definition of subtyping in terms of subset inclusion of the corresponding sets of shapes.

An array T[] is iterable as a sequence of values of type T.

5.2.1.2 Tuple types

A tuple type descriptor describes a type of list value by specifying a separate type for each member of the list.

tuple-type-descriptor :=
   [ tuple-member-type-descriptors ]
tuple-member-type-descriptors :=
   member-type-descriptor (, member-type-descriptor)* [, tuple-rest-descriptor]
   | [ tuple-rest-descriptor ]
tuple-rest-descriptor := type-descriptor ...

A tuple type descriptor T with m member type descriptors contains a list shape L of length n if and only if:

m is less than or equal to n
the i-th member type descriptor of T contains the i-th member of L for each i from 1 to m;
if n is greater than m, then T has a tuple-rest-descriptor R..., and R contains the j-th member of L for each j from m + 1 to n.

Note that a tuple type where all the member-type-descriptors are the same and there is no tuple-rest-descriptor is equivalent to an array-type-descriptor with a length.

5.2.2 Mappings

A mapping value is a container where each member has a key, which is a string, that uniquely identifies within the mapping. We use the term field to mean the member together its key; the name of the field is the key, and the value of the field is that value of the member; no two fields in a mapping value can have the same name.

The shape of a mapping value is an unordered collection of field shapes one for each field. The field shape for a field f has a name, which is the same as the name of f, and a shape, which is the shape of the value of f.

A mapping is iterable as a sequence of its members. The order of the members is implementation-dependent, but implementations are encouraged to preserve and use the order in which the fields were added.

The type of mapping values can be described by two kinds of type descriptors.

mapping-type-descriptor :=
   map-type-descriptor | record-type-descriptor

The inherent type of a mapping value must be a mapping-type-descriptor. The inherent type of a mapping value determines a type T_f for the value of the field with name f. The runtime system will enforce a constraint that a value written to field f will belong to type T_f. Note that the constraint is not merely that the value looks like T_f.

Both kinds of type descriptor are covariant in the types of their members.

5.2.2.1 Map types

A map type-descriptor describes a type of mapping value by specifying the type that the value for all fields must belong to.

map-type-descriptor := map type-parameter
type-parameter := < type-descriptor >

A type map<T> contains a mapping shape m if every field shape in m has a value shape that is in T.

A value belonging to type map<T> is iterable as a sequence of values of type T.

If a type descriptor T has lax static typing, then the type map<T> also has lax static typing.

5.2.2.2 Record types

A record type descriptor describes a type of mapping value by specifying a type separately for the value of each field.

record-type-descriptor :=
   inclusive-record-type-descriptor | exclusive-record-type-descriptor
inclusive-record-type-descriptor :=
   record { field-descriptor* }
exclusive-record-type-descriptor :=
   record {| field-descriptor* [record-rest-descriptor] |}
field-descriptor :=
   individual-field-descriptor | record-type-reference
individual-field-descriptor :=
   type-descriptor field-name [? | default-value] ;
field-name := identifier
default-value := = expression
record-type-reference := * type-reference ;
record-rest-descriptor := type-descriptor ... ;

Each individual-field-descriptor specifies an additional constraint that a mapping value shape must satisfy for it to be a member of the described type. The constraint depends on whether ? is present:

if ? is not present, then the constraint is that the mapping value shape must have a field shape with the specified field-name and with a value shape that is a member of the specified type-descriptor; this is called a required field;
if ? is present, then the constraint is that if the mapping value shape has a field shape with the specified field-name, then its value shape must be a member of the specified type-descriptor; this is called an optional field.

The order of the individual-field-descriptors within a record-type-descriptor is not significant. Note that the delimited identifier syntax allows the field name to be any non-empty string.

An exclusive-record-type-descriptor, which uses the {| and |} delimiters, allows exclusively the fields described. More precisely, for a mapping value shape and a record-type-descriptor, let the extra field shapes be the field shapes of the mapping value shapes whose names are not the same as field-name of any individual-field-descriptor; a mapping value shape is a member of the type described by an exclusive-record-type-descriptor only if either:

there are no extra fields shapes, or
there is a record-rest-descriptor T..., and the value shape of every extra field shape is a member of T.

An inclusive-record-type-descriptor, which uses the { and } delimiters, allows any mapping value that includes the fields described, provided that the other fields are pure and not errors. More precisely, a type descriptor record { F }; is equivalent to record {| F; T...; |}, where T is the type that contains all pure shapes other than errors, which can be written as anydata.

A record type descriptor that either is an inclusive-record-type-descriptor or is an exclusive-record-type-descriptor with a record-rest-descriptor is called open; a record type descriptor that is not open is called closed.

A default-value specifies a default value for the field, which is used when the record type descriptor is used to construct a mapping value but no value is specified explicitly for the field. The type descriptor contains a 0-argument function closure for each default value. The closure is created from the expression when the type descriptor is resolved. The closure is evaluated to create a field value each time the default is used in the construction of a mapping value. The default value does not affect the type described by the type descriptor.

A record-type-reference pulls in fields from a named record type. The type-reference must reference a type described by a record-type-descriptor. The field-descriptors and any record-rest-descriptor are copied into the type being defined; the meaning is the same as if they had been specified explicitly. For default values, the closure rather than the expression is copied in. A record-rest-descriptor in the referencing type overrides any record-rest-descriptor in the referenced type. For the purposes of resolving a record-type-reference, a referenced or referencing type that is an inclusive-record-type-descriptor is treated as if it were the equivalent exclusive-record-type-descriptor with an explicit record-rest-descriptor.

5.2.3 [Preview] Tables

A table is intended to be similar to the table of relational database table. A table value contains an immutable set of column names and a mutable bag of rows. Each column name is a string; each row is a mapping that associates a value with every column name; a bag of rows is a collection of rows that is unordered and allows duplicates.

A table value also contains a boolean flag for each column name saying whether that column is a primary key for the table; this flag is immutable. If no columns have this flag, then the table does not have a primary key. Otherwise the value for all primary keys together must uniquely identify each row in the table; in other words, a table cannot have two rows where for every column marked as a primary key, that value of that column in both rows is the same.

table-type-descriptor := direct-table-type-descriptor | indirect-table-type-descriptor
direct-table-type-descriptor := table { column-type-descriptor+ }
indirect-table-type-descriptor := table type-parameter

column-type-descriptor :=
   individual-column-type-descriptor
   | column-record-type-reference
individual-column-type-descriptor :=
   [key] type-descriptor column-name ;
column-record-type-reference :=
   * type-reference [key-specifier (, key-specifier)*] ;
key-specifier := key column-name
column-name := identifier

A direct-table-type-descriptor has a descriptor for each column, which specifies the name of the column, whether that column is part of a primary key and the type that values in that column must belong to. The type descriptor for the column must be a pure type. If a column is part of a primary key, then the type descriptor for the column must also allow only non-nil simple values.

An indirect-table-type-descriptor describes a table type in terms of the shape of the the rows of the table. A type table<T> contains a table shape if T contains the mapping shape of every member of the table shape. If T is a closed record type, then table<T> is equivalent to table { *T; }.

Note that a table type T' will be a subtype of a table type T if and only if:

T and T' have the same set of column names;
T and T' have the same set of primary keys; and
for each column, the type for that column in T' is a subtype of the type of that column in T.

A table is iterable as a sequence of mapping values, one for each row; the inherent type of each mapping value will be a closed record type.

5.2.4 [Preview] XML

xml-type-descriptor := xml

An XML value represents a sequence of zero or more of the items that can occur inside an XML element, specifically:

elements
characters
processing instructions
comments

A single XML item, such as an element, is represented by a sequence consisting of just that item; these are called singleton xml values. The attributes of an element are represented by a map<string>. The content of each element in the sequence is itself a distinct XML value.

The name of an XML element or attribute, which in the XML Information Set is represented by a combination of the [namespace name] and [local name] properties, is represented by a single string. If the [namespace name] property has no value, then the string consists of just the value of the [local name] property; otherwise, the string is of the form:

   {namespace-name}local-name

where namespace-name and local-name are the values of the [namespace name] and [local name] properties respectively. The attributes of an XML element include attributes that appear as members of the [namespace attributes] property of an element information item, as well as those that appear as members of the [attributes] property.

XML values allow mutation in a different way from containers. Element items can be mutated; in particular, an element can be mutated to change its content to be another XML value. But other items are immutable. Furthermore, once an XML value is constructed, which items comprise the sequence it represents is fixed. Thus an XML value consising of only character items is immutable in the same way as a string.

An XML value is iterable as a sequence of its items, where each character item is represented by a string of length one and other items are represented by a singleton XML value.

5.2.5 Error

error-type-descriptor := error [error-type-params]
error-type-params := < (explicit-error-type-params | inferred-error-type-param) >
explicit-error-type-params := reason-type-descriptor [, detail-type-descriptor]
reason-type-descriptor := type-descriptor
detail-type-descriptor := type-descriptor
inferred-error-type-param := *

An error value belongs to the error basic type, which is a basic type which is distinct from other structured types and is used only for representing errors. The error type is inherently immutable. An error value contains the following information:

a reason, which is a string identifier for the category of error
a detail, which is an immutable mapping providing additional information about the error
a stack trace, which is an immutable snapshot of the state of the execution stack

A module-qualified reason string is a string that has the form

   {org-name/module-name}identifier

where org-name, module-name and identifier are as defined by the grammar in this specification, but with no whitespace allowed between tokens. Any reason string that starts with a { should be a module-qualified reason string. Any error value that is constructed as the associated value of a panic will use a module-qualified reason with an org-name of ballerina and a module-name that starts with lang., as will any error value constructed by a function in the lang library.

The detail mapping must belong to the following type, which is provided as type Detail in the lang.error module of the lang library:

record {|
   string message?;
   error cause?;
   (anydata|error)...;
|};

The shape of an error value consists of the shape of the reason and the shape of the detail; the stack trace is not part of the shape. A type descriptor error<r, d> contains an error shape if r contains the shape's reason, and d, if present, contains the shape's detail. The bare type error contains all error shapes. The reason-type-descriptor must be a subtype of string. The detail-type-descriptor must be a subtype of the Detail type, and defaults to the Detail type if omitted.

A type of error<*> means that the type is a subtype of error, where the precise subtype is to be inferred from the context. This is allowed only within type descriptors occurring in a context that is specified to be inferable.

Error is the only structured basic type that is not iterable.

5.3 Behavioral values

behavioral-type-descriptor :=
   function-type-descriptor
   | object-type-descriptor
   | future-type-descriptor
   | service-type-descriptor
   | typedesc-type-descriptor
   | handle-type-descriptor

5.3.1 Functions

function-type-descriptor := function function-signature
function-signature := ( param-list ) return-type-descriptor
return-type-descriptor := [ returns [annots] type-descriptor ]

A function is a part of a program that can be explicitly executed. In Ballerina, a function is also a value, implying that it can be stored in variables, and passed to or returned from functions. When a function is executed, it is passed an argument list as input and returns a value as output.

When the execution of a function returns to its caller, it returns exactly one value. A function that would in other programming languages not return a value is represented in Ballerina by a function returning (). Note that the function definition does not have to explicitly return (); a return statement or falling off the end of the function body will implicitly return ().

param-list :=
   required-params [, defaultable-params] [, rest-param]
   | defaultable-params [, rest-param]
   | [rest-param]
required-params := required-param (, required-param)*
required-param := [annots] [public] type-descriptor [param-name]
defaultable-params := defaultable-param (, defaultable-param)*
defaultable-param := [annots] [public] type-descriptor [param-name] default-value
rest-param := [annots] type-descriptor ... [param-name]
param-name := identifier

A param-name can be omitted from a required-param, defaultable-param or rest-param only when occuring in the function-signature of a function-type-descriptor.

The argument list passed to a function consists of zero or more arguments in order; each argument is a value, but the argument list itself is not passed as a value. The argument list must conform to the param-list as described in this section. Usually, the compiler's type checking will ensure that this is the case; if not, the function will panic.

It is convenient to consider the complete param-list as having a type. This type is described by a tuple-type-descriptor that has a member-type-descriptor for each required-param and defaultable-param, and has a tuple-rest-descriptor if and only if there is a rest-param. The i-th member-type-descriptor of the tuple type descriptor is the same as the type-descriptor of the i-th member of the param-list; the type-descriptor of the tuple-rest-descriptor, if present, is the same as the type-descriptor of the rest-param.

An argument list consisting of values v₁,..., v_n conforms to a param-list that has type P, if and only if for each i with 1 <= i <= n, vi belongs to T_i, where T_i is defined to be the type that contains a shape s if and only if P contains a list shape whose i-th member is s.

When an argument list is passed to a function, the non-rest parameters are initialized from the arguments in the argument list in order. The conformance of the argument list to the param-list declared for the function ensures that each parameter will be initialized to a value that belongs to the declared type of the parameter. If there is a rest-param, then that is a initialized to a newly created lists containing the remaining arguments in the argument-list; the inherent type of this list will be T[] where T is the type of the rest-param. The conformance of the argument list ensures that the members of this list will belong to type T.

A defaultable-param is a parameter for which a default value is specified. The expression specifying the default value may refer to previous parameters by name. For each defaultable parameter, the function's type descriptor includes a closure that computes the default value for the parameter using the values of previous parameters. The caller of the function uses the closures in the function's type descriptor to compute default values for any defaultable arguments that were not specified explicitly. These default values are included in the argument list passed to the function. Whether a parameter is defaultable, and what its default is, do not affect the shape of the function and thus do not affect typing. The closures computing the defaultable parameters are created when the type descriptor is resolved; the default value is computed by calling the closure each time the function is called and the corresponding parameter is not specified. Whether a parameter is defaultable is used at compile time, but the closure that computes the default value is only used at runtime.

The name of each parameter is included in the function's type descriptor. A caller of the function may specify the name of the parameter that an argument is supplying. In this case, the caller uses the parameter name at compile time in conjunction with the type descriptor to create the argument list. For each parameter name, the function's type descriptor also includes the region of code within which the name of the parameter is visible; as usual, if public is specified, the region is the entire program, otherwise it is the module in which the function type descriptor occurs. The name of a parameter can only be used to specify an argument in a function call that occurs within the region of code within which the parameter name is visible. The parameter names do not affect the shape of the function and thus do not affect typing.

The process by which the function caller creates an argument list, which may make use of arguments specified both by position and by name, is described in more detail in the section on function calls.

Function types are covariant in their return types and contravariant in the type of their parameter lists. More precisely, a function type with return type R and parameter list type P is a subtype of a function type with return type R' and parameter list type P' if and only if R is a subtype of R' and P' is a subtype of P. A function value f belongs to a function type T if the declared type of f is a subtype of T.

5.3.2 Objects

Objects are a combination of fields along with a set of associated functions, called methods, which can be used to manipulate them. An object's methods are associated with the object when the object is constructed and cannot be changed thereafter. The fields and methods of an object are in separate symbol spaces, so it is possible for an object to have a field and a method with the same name.

An object type descriptor, in addition to describing the object type, also defines a way to construct an object of this type, in particular it provides the method definitions that are associated with the object when it is constructed.

It is also possible to have an object type descriptor that only describes an object type and cannot be used to construct an object; this is called an abstract object type descriptor.

object-type-descriptor :=
   object-type-quals object {
      object-member-descriptor*
   }
object-type-quals :=
   [abstract] [client] | [client] abstract
object-member-descriptor :=
   object-field-descriptor
   | object-method
   | object-type-reference

If object-type-quals contains the keyword abstract, then the object type descriptor is an abstract object type descriptor.

If object-type-quals contains the keyword client, then the object type is a client object type. A client object type may have remote methods; other objects types must not.

5.3.2.1 Fields

object-field-descriptor :=
   object-visibility-qual type-descriptor field-name [default-value];

An object-field-descriptor specifies a field of the object. The names of all the fields of an object must be distinct.

5.3.2.2 Methods

Methods are functions that are associated to the object and are called via a value of that type using a method-call-expr.

object-method := method-decl | method-defn
method-decl :=
   metadata
   method-defn-quals
   function method-name function-signature ;
method-defn :=
   metadata
   method-defn-quals
   function method-name function-signature method-body
method-defn-quals := object-visibility-qual [remote]
method-name := identifier
method-body := function-body

The names of all the methods of an object must be distinct: there is no method overloading. Method names beginning with two underscores are reserved for use with semantics defined by this specification, either as the __init method or as a method declared by a built-in abstract object types.

Within a method-body, the fields and methods of the object are not implicitly in-scope; instead the keyword self is bound to the object and can be used to access fields and methods of the object.

If an object type is abstract, every method must be specified using a method-decl. Otherwise every method must be specified using a method-defn.

A method that is declared or defined with the remote qualifier is a remote method. A remote method is allowed only in a client object. A remote method is invoked using a different syntax from a non-remote method.

5.3.2.3 Visibility

object-visibility-qual := [explicit-visibility-qual]
explicit-visibility-qual := public | private

Each field and method of an object type is visible within and can be accessed from a specific region of code, which is specified by its object-visibility-qual as follows:

if the object-visibility qual is private, then the visibility region consists of the methods defined by this object type descriptor;
if the object-visibility-qual is empty, then the visibility region is the entire module containing this object type descriptor; this is called module-level visibility;
if the object-visibility-qual is public, then the visibility region contains all modules.

The visibility of a method or field of an abstract object type cannot be private.

5.3.2.4 Typing

The shape of an object consists of an unordered collection of object field shapes and an unordered collection of object method shapes. An object field shape or object method shape is a triple consisting of the name of the field or method, the visibility region, and a shape for the value of the field or for the method's function.

An object type is inclusive, in a similar way to an inclusive-record-type-descriptor: an object shape belongs to an object type if it has at least the fields and methods described in the object-type-descriptor. Thus all object values belong to the type object { }.

An object-type-descriptor that has a field with name f, visibility region R and type T contains an object shape only if the object shape contains an object field shape that has name f, visibility region R and a value shape that is contained in T. An object-type-descriptor that has a method with name m, visibility region R and function type T contains an object shape only if the object shape contains an object method shape that has name m, visibility region R and a function value that belongs to type T.

Thus an object type T' is a subtype of an object type T only if for each field or method f of T there is a corresponding field or method f' of T such that the type of f' in T' is a subtype of the type of f in T and the visibility region of f' in T' is the same as the visibility region of f in T.

This implies that:

if an object type descriptor T has private fields or methods, then it is not possible to define another object type descriptor that is a subtype of T, and
if an object type descriptor T has fields or methods with module-level visibility, then it is possible to define another object type descriptor that is a subtype of T only within the same module as T.

5.3.2.5 Initialization

A non-abstract object type provides a way to initialize an object of the type. An object is initialized by:

allocating storage for the object
initializing each field with its default value, if it has one
initializing the methods of the object using the type's method definitions
calling the object's __init method, if there is one

The return type of the __init method must be a subtype of the union of error and nil, and must contain nil; if __init returns an error, it means that initialization of the object failed. The __init method can declare parameters in the same way as any other method.

At any point in the body of a __init method, the compiler determines which fields are potentially uninitialized. A field is potentially uninitialized at some point if that field does not have a default value and it is not definitely assigned at that point. It is a compile error if a __init method:

accesses a field at a point where it is potentially initialized, or
at a point where there is any potentially uninitialized field
- returns nil, or
- uses the self variable other than to access or modify the value of a field.

An object must have an __init method unless all its fields have a default value. An object without an __init method behaves as it had an __init method with no parameters and an empty body (which will always return nil).

The visibility of the __init method cannot be private.

Any __init method is not part of the shape of an object, and so does not affect when an object value belongs to a type. An abstract object type must not declare an __init object. The __init method can be called in a method-call-expr only when the expression preceding the . is self.

5.3.2.6 Object type references

object-type-reference :=
   * type-reference ;

The type-reference in an object-type-reference must reference an abstract object type. The object-member-descriptors from the referenced type are copied into the type being defined; the meaning is the same as if they had been specified explicitly.

If a non-abstract object type T_o has a type reference to an abstract object type T_a, then each method declared in T_a must be defined in T_o using a method-defn with the same visibility. If T_a has a method or field with module-level visibility, the T_o must be in the same module.

5.3.3 Futures

future-type-descriptor := future [type-parameter]

A future value refers to a named worker, which will return a value. A future value belongs to a type future<T> if the return type of the named worker is a subtype of T.

A value belongs to a type future (without the type-parameter) if it has basic type future.

5.3.4 [Preview] Services

service-type-descriptor := service

A service is like an object, but differs in the following respects:

a method of a service can be declared as a resource method, but cannot be declared as a remote method
a service is stateless and does not have fields

A resource method is a special kind of method, with associated configuration data, that is invoked in response to network messages received by a Listener. A service can be thought of as the dual of a client object.

All service values belong to the type service.

It is planned that a future version of Ballerina will provide a mechanism that allows more precise typing of services. In the meantime, implementations can use annotations on type definitions to support this.

5.3.5 Type descriptors

typedesc-type-descriptor := typedesc [type-parameter]

A type descriptor value is an immutable value representing a resolved type descriptor. The type typedesc contains all values with basic type typedesc. A typedesc value t belongs to a type typedesc<T> if and only if the type described by t is a subtype of T. The typedesc type is thus covariant with its type parameter.

Referencing an identifier defined by a type definition in an expression context will result in a type descriptor value.

5.3.6 Handles

handle-type-descriptor := handle

A handle value is a reference to storage managed externally to a Ballerina program. Handle values are useful only in conjunction with functions that have external function bodies; in particular, a new handle value can be created only by a function with an external function body.

A value belongs to a type handle if it has a basic type of handle.

5.4 Other type descriptors

other-type-descriptor :=
   type-reference
   | ( type-descriptor )
   | singleton-type-descriptor
   | union-type-descriptor
   | optional-type-descriptor
   | any-type-descriptor
   | anydata-type-descriptor
   | byte-type-descriptor
   | json-type-descriptor
type-reference := identifier | qualified-identifier

A type-reference must refer to a type definition.

It is important to understand that the type descriptors specified in this section do not add to the universe of values. They are just adding new ways to describe subsets of this universe.

5.4.1 Singleton types

singleton-type-descriptor := simple-const-expr

A singleton type is a type containing a single shape. A singleton type is described using an compile-time constant expression for a single value: the type contains the shape of that value. Note that it is possible for the variable-reference within the simple-const-expr to reference a structured value.

5.4.2 Union types

union-type-descriptor := type-descriptor | type-descriptor

The value space of a union type T1|T2 is the union of T1 and T2.

5.4.3 Optional types

optional-type-descriptor := type-descriptor ?

A type T? means T optionally, and is exactly equivalent to T|().

5.4.4 Any type

any-type-descriptor := any

The type descriptor any describes the type consisting of all values other than errors. A value belongs to the any type if and only if its basic type is not error. Thus all values belong to the type any|error. Note that a structure with members that are errors belongs to the any type.

5.4.5 Anydata type

anydata-type-descriptor := anydata

The type descriptor anydata describes the type of all pure values other than errors. The type anydata contains a shape if and only if the shape is pure and is not the shape of an error value.

Note that anydata allows structures whose members are errors. Thus the type anydata|error is the supertype of all pure types. The type anydata is equivalent to the union

  () | boolean | int | float | decimal | string
    | (anydata|error)[] | map<anydata|error>
    | xml | table

5.4.6 Byte type

byte-type-descriptor := byte

The byte type is a built-in name for a union of the int values in the range 0 to 255 inclusive.

5.4.7 JSON types

json-type-descriptor := json

The json type is designed for processing data expression in JSON format. It is a built-in name for a union defined as follows:

type json = () | boolean | int | float | decimal | string | json[] | map<json>;

In addition, the json type is defined to have lax static typing.

5.5 Built-in abstract object types

There are several abstract object types that are built-in in the sense that the language treats objects with these types specially. Note that it is only the types that are built-in; the names of these types are not built-in.

5.5.1 Iterator

A value that is iterable as a sequence of values of type T provides a way of creating an iterator object that matches the type

    abstract object {
       public next() returns record {| T value; |}?;
    }

In this specification, we refer to this type as Iterator<T>.

Conceptually an iterator represents a position between members of the sequence. Possible positions are at the beginning (immediately before the first member if any), between members and at the end (immediately after the last member if any). A newly created iterator is at the beginning position. For an empty sequence, there is only one possible position which is both at the beginning and at the end.

The next() method behaves as follows:

if the iterator is currently at the end position, return nil
otherwise
- move the iterator to next position, and
- return a record { value: v } where v is the member of the sequence between the previous position and the new position

Mutation of the container during iteration is handled as follows. At any point during the execution of a program, a container has a set of valid keys; these are keys for which the container has a member; a key has type int for lists and type string for maps. A call to next() must panic if the set of valid keys is not the same as the set of valid keys when the iterator was created, with the following exception: it is allowed to remove a key if the member for that key has already been returned by next(). The value that a container associates with a particular key may change during the iteration; next() must return the value associated with the key at the point when next() is called.

Note that it is not possible for the next() method simply to return a member of the sequence, since a nil member would be indistinguishable from the return value for the end position.

5.5.2 Iterable

An object can make itself be iterable as a sequence of values of type T by providing a method named __iterator which returns a value that is a subtype of Iterator<T>. In this specification, we refer to this type as Iterable<T>.

5.5.3 Listener

The Listener type is defined as follows.

abstract object {
   public function __attach(service s, string? name = ()) returns error?;
   public function __detach(service s) returns error?;
   public function __start() returns error?;
   public function __gracefulStop() returns error?;
   public function __immediateStop() returns error?;
}

Note that if an implementation does precise service typing using annotations on type definitions, it will need to treat Listener as being parameterized in the precise service type that is used to the first argument to __attach.

5.6 Abstract operations

These section specifies a number of operations that can be performed on values. These operations are for internal use by the specification. These operations are named in CamelCase with an initial upper-case letter to distinguish them from functions in the lang library.

5.6.1 FillMember

The FillMember(c, k) operation is defined for a container value c and a key value k. It can be performed when c does not have a member with key k; if it succeeds, it will result in a member with key k being added to c. It will succeed if the inherent type of c allows the addition of a member with key k and there is a way to construct a filler value for the type descriptor that the inherent type of c requires for member k. The following table specifies when and how a filler value can be constructed for a type descriptor.

Type descriptor	Filler value	When available
`()`	`()`
`boolean`	`false`
`int`	`0`
`float`	`+0.0f`
`decimal`	`+0.0d`
`string`	`""`
list type descriptor	`[]`	if that is a valid constructor for the type
mapping type descriptor	`{ }`	if that is a valid constructor for the type
table	empty table (with no rows)
object	`new T()`	if this is valid and its static type does not include error, where `T` is the object type descriptor (an abstract object type will not have a filler value)
`xml`	xml``
singleton	the single value used to specify the type
union	`()`	if `()` is a member of the union
union	the filler value for basic type B	if all members of the union belong to a single basic type B, and the filler value for B also belongs to the union
`T?`	`()`
`any`	`()`
`anydata`	`()`
`byte`	`0`
`json`	`()`

5.6.2 Clone

Clone(v) is defined for any pure value v. It performs a deep copy, recursively copying all structural values and their members. Clone(v) for a immutable value v returns v. If v is a container, Clone(v) has the same inherent type as v. The graph of references of Clone(v) must have the same structure as that of v. This implies that the number of distinct references reachable from Clone(v) must be the same as the number of distinct references reachable from v. Clone(v) must terminate for any pure value v, even if v has cycles.

Clone(v) cannot be implemented simply by recursively calling Clone on all members of v. Rather Clone must maintain a map that records the result of cloning each reference value. When a Clone operation starts, this map as empty. When cloning a reference value, it must use the result recorded in the map if there is one.

The Clone operation is exposed by the clone function in the lang.value module of the lang library.

5.6.3 ImmutableClone

ImmutableClone(v) is defined for any pure value v. It performs a deep copy of v similar to Clone(v), except that newly constructed values are constructed as immutable. Any immutable value is not copied.

Like Clone, ImmutableClone must preserve graph structure, including cycles. Conceptually the whole graph is constructed before being made immutable.

The ImmutableClone operation is exposed by the cloneReadOnly function in the lang.value module of the lang library.

5.6.4 SameShape

SameShape(v1, v2) is defined for any pure values v1, v2. It returns true or false depending of whether v1 and v2 have the same shape. SameShape(v1, v2) must terminate for any pure values v1 and v2, even if v1 or v2 have cycles. SameShape(v1, v2) returns true if v1 and v2 have the same shape, even if the graphs of references of v1 and v2 have different structures. If two values v1 and v2 have different basic types, then SameShape(v1, v2) will be false.

The possibility of cycles means that SameShape cannot be implemented simply by calling SameShape recursively on members. Rather SameShape must maintain a mapping that records for each pair of references whether it is already in process of comparing those references. When a SameShape operation starts, this map is empty. Whenever it starts to compare two references, it should see whether it has already recorded that pair (in either order), and, if it has, proceed on the assumption that they compare equal.

SameShape(Clone(x), x) is guaranteed to be true for any pure value.

5.6.5 NumericConvert

NumericConvert(t, v) is defined if t is the typedesc for float, decimal or int, and v is a numeric value. It converts v to a value in t, or returns an error, according to the following table.

from \ to	float	decimal	int
float	unchanged	closest math value	round, error for NaN or out of int range
decimal	closest math value	unchanged	round, error for NaN or out of int range
int	same math value	same math value	unchanged

5.7 Binding patterns and variables

5.7.1 Binding patterns

Binding patterns are used to support destructuring, which allows different parts of a single structured value each to be assigned to separate variables at the same time.

binding-pattern :=
   capture-binding-pattern
   | wildcard-binding-pattern
   | list-binding-pattern
   | mapping-binding-pattern
   | error-binding-pattern
capture-binding-pattern := variable-name
variable-name := identifier
wildcard-binding-pattern := _
list-binding-pattern := [ list-member-binding-patterns ]
list-member-binding-patterns :=
   binding-pattern (, binding-pattern)* [, rest-binding-pattern]
   | [ rest-binding-pattern ]
mapping-binding-pattern := { field-binding-patterns }
field-binding-patterns :=
   field-binding-pattern (, field-binding-pattern)* [, rest-binding-pattern]
   | [ rest-binding-pattern ] 
field-binding-pattern :=
   field-name : binding-pattern
   | variable-name
rest-binding-pattern := ... variable-name
error-binding-pattern := direct-error-binding-pattern | indirect-error-binding-pattern
direct-error-binding-pattern := error ( direct-error-arg-list-binding-pattern )
indirect-error-binding-pattern := error-type-reference ( indirect-error-arg-list-binding-pattern )
error-type-reference := type-reference
direct-error-arg-list-binding-pattern :=
   simple-binding-pattern [, error-field-binding-patterns]
   | [error-field-binding-patterns]
indirect-error-arg-list-binding-pattern := [error-field-binding-patterns]
error-field-binding-patterns :=
   named-arg-binding-pattern (, named-arg-binding-pattern)* [, rest-binding-pattern]
   | rest-binding-pattern
simple-binding-pattern :=
   capture-binding-pattern
   | wildcard-binding-pattern
named-arg-binding-pattern := arg-name = binding-pattern

A binding pattern may succeed or fail in matching a value. A successful match causes values to be assigned to all the variables occurring the binding-pattern.

A binding pattern matches a value in any of the following cases.

a capture-binding-pattern always matches a value and causes the matched value to be assigned to named variable;
a wildcard-binding-pattern matches a value if the value belongs to type any, in other words if the basic type of the value is not error; it does not cause any assignments to be made;
a list-binding-pattern with m binding patterns matches a list with n members if m is less than or equal to n, and the i-th binding pattern matches the i-th member of the list for each i in 1 to m, and either m is equal to n or the list-binding-pattern includes a rest-binding-pattern; if there is a rest-binding-pattern ...v, then a successful match causes a new list value consisting of all members of the matched list except for the the first m values to be assigned to v;
a mapping-binding-pattern { f₁: p₁, f₂: p₂, ..., f_n: p_n, r } matches a mapping value m that includes fields f₁, f₂, ... , f_n if p_i matches the value of field f_i for each i in 1 to n; if r is ...v then a successful match causes a new mapping value consisting of all the other fields to be assigned to v; a field-binding-pattern consisting of just a variable-name x is equivalent to a field-binding-pattern x: x;
a direct-error-binding-pattern error(p_r, f₁ = p₁, f₂ = p₂, ..., f_n = p_n, r) matches an error value if it has an error reason string that matches p_r and a detail record that has fields f₁, f₂, ... , f_n such that p_i matches the value of field f_i for each i in 1 to n; if r is ...v then a successful match causes a new mapping value consisting of all fields other than f₁, f₂, ... , f_n to be assigned to v;
an indirect-error-binding-pattern ET(f₁ = p₁, f₂ = p₂, ..., f_n = p_n, r) matches an error value e if the direct-error-binding-pattern error(f₁ = p₁, f₂ = p₂, ..., f_n = p_n, r) matches e and the shape of e is in ET.

All the variables in a binding-pattern must be distinct e.g. [x, x] is not allowed.

Given a type descriptor for every variable in a binding-pattern, there is a type descriptor for the binding-pattern that will contain a value just in case that the binding pattern successfully matches the value causing each variable to be assigned a value belonging to the type descriptor for that variable.

for a capture-binding-pattern, the type descriptor is the type descriptor for that variable;
for a wildcard-binding-pattern, the type descriptor is any
for a list-binding-pattern, the type descriptor is a tuple type descriptor;
for a mapping-binding-pattern, the type descriptor is a record type descriptor;
for an error-binding-pattern, the type descriptor is an error type descriptor.

5.7.2 Typed binding patterns

typed-binding-pattern := inferable-type-descriptor binding-pattern
inferable-type-descriptor := type-descriptor | var

A typed-binding-pattern combines a type-descriptor and a binding-pattern, and is used to create the variables occurring in the binding-pattern. If var is used instead of a type-descriptor, it means the type is inferred. How the type is inferred depends on the context of the typed-binding-pattern. An inferable-type-descriptor is an inferable context for a type descriptor, which means that * can be used with the type descriptor to infer certain parts of it.

The simplest and most common form of a typed-binding-pattern is for the binding pattern to consist of just a variable name. In this case, the variable is constrained to contain only values matching the type descriptor.

When the binding pattern is more complicated, the binding pattern must be consistent with the type-descriptor, so that the type-descriptor unambiguously determines a type for each variable occurring in the binding pattern. A binding pattern occurring in a typed-binding-pattern must also be irrefutable with respect to the type of value against which it is to be matched. In other words, the compiler will ensure that matching such a binding pattern against a value will never fail at runtime.

5.7.3 Variable and identifier scoping

For every variable, there is place in the program that declares it. Variables are lexically scoped: every variable declaration has a scope which determines the region of the program within which the variable can be referenced.

There are two kinds of scope: module-scope and block-scope. A variable with module-scope can be referenced anywhere within a module; if declared public, it can also be referenced from outside the module.

Identifiers with module-scope are used to identify not only variables but other module-level entities such as functions. Within module-scope, identifiers are separated into three symbol spaces:

the main symbol space includes identifiers for variables, constants, types, functions and other identifiers that do not belong to any of the other two symbol spaces;
the prefix symbol space contains prefixes declared by import declarations and XML namespace declaration statements;
the annotation tag symbol space contains annotation tags declared by annotation declarations.

The prefix symbol space is special in that it is associated with a source part rather than a module.

Block-scope is divided into symbol spaces in the same way as module-scope, except that block-scope does not have a symbol space for annotation tags, since annotation tags cannot be declared with block-scope.

An identifier declared with block-scope can be referenced only within a particular block (always delimited with curly braces). Block-scope variables are created by a variety of different constructs, many of which use a typed-binding-pattern. Parameters are treated as read-only variables with block-scope.

It is not an error if an identifier is declared with block-scope and there is already a declaration of the same identifier in the same symbol space with module-scope. In this case, the block-scope declaration will hide the module-scope declaration for the region where the block-scope declaration is in scope. However, it is a compile error if an identifier is declared with block-scope and its scope overlaps with the scope of another declaration of the same identifier in the same symbol space also with block-scope.

6. Expressions

expression := 
   literal
   | list-constructor-expr
   | mapping-constructor-expr
   | table-constructor-expr
   | service-constructor-expr
   | string-template-expr
   | xml-expr
   | new-expr
   | variable-reference-expr
   | field-access-expr
   | optional-field-access-expr
   | annot-access-expr
   | member-access-expr
   | xml-attributes-expr
   | function-call-expr
   | method-call-expr
   | error-constructor-expr
   | anonymous-function-expr
   | arrow-function-expr
   | type-cast-expr
   | typeof-expr
   | unary-expr
   | multiplicative-expr
   | additive-expr
   | shift-expr
   | range-expr
   | numerical-comparison-expr
   | is-expr
   | equality-expr
   | binary-bitwise-expr
   | logical-expr
   | conditional-expr
   | checking-expr
   | trap-expr
   | ( expression )

For simplicity, the expression grammar is ambiguous. The following table shows the various types of expression in decreasing order of precedence, together with associativity.

Operator	Associativity
`x.k` `x.@a` `f(x)` `x.f(y)` `x[y]` `new T(x)`
`+x` `-x` `~x` `!x` `<T> x` `typeof x`
`x * y` `x / y` `x % y`	left
`x + y` `x - y`	left
`x << y` `x >> y` `>>>`	left
`x ... y` `x ..< y`	non
`x < y` `x > y` `x <= y` `x >= y` `x is y`	non
`x == y` `x != y` `x === y` `x !== y`	left
`x & y`	left
`x ^ y`	left
`x \| y`	left
`x && y`	left
`x \|\| y`	left
`x ?: y`	right
`x ? y : z`	right
`(x) => y`	right

6.1 Expression evaluation

When the evaluation of an expression completes normally, it produces a result, which is a value. The evaluation of an expression may also complete abruptly. There are two kinds of abrupt completion: check-fail and panic. With both kinds of abrupt completion there is an associated value, which always has basic type error.

The following sections describes how each kind expression is evaluated, assuming that evaluation of subexpressions complete normally. Except where explicitly stated to the contrary, expressions handle abrupt completion of subexpressions as follows. If in the course of evaluating an expression E, the evaluation of some subexpression E1 completes abruptly, then then evaluation of E also completes abruptly in the same way as E1.

6.2 Static typing of expressions

A type is computed for every expression at compile type; this is called the static type of the expression. The compiler and runtime together guarantee that if the evaluation of an expression at runtime completes normally, then the resulting value will belong to the static type. A type is also computed for check-fail abrupt completion, which will be a (possibly empty) subtype of error; however, for panic abrupt completion, no type is computed.

The detailed rules for the static typing of expressions are quite elaborate and are not yet specified completely in this document.

6.2.1 Lax static typing

In some situations it is convenient for static typing to be less strict than normal. One such situation is when processing data in Ballerina using a static type that is less precisse than the type that the data is in fact expected to belong to. For example, when the Ballerina json type is used for the processing of data in JSON format, the Ballerina static type will not capture the constraints of the particular JSON format that is been processed.

Ballerina supports this situation through the concept of lax static typing, which has two parts: the first part is that a type descriptor can be classified as lax; the second part is that particular kinds of expression can have less strict static typing rules when the static type of a subexpression is described by a lax type descriptor. With these less strict rules, a potential type error that would have been a compile-time error according to the normal strict static typing rules would instead be allowed at compile-time and result in an error value at runtime; the effect is thus that some static type-checking is instead done dynamically.

In this version of Ballerina, only the first step has been taken towards supporting this concept. There is a fixed set of type descriptors that are classified as lax: specifically json is lax, and map<T> is lax if T is lax. The only kinds of expression for which lax typing rules are specified are field-access-expr and optional-field-access-expr.

6.2.2 Contextually expected type

For a context in which an expression occurs, there may be a type descriptor that describes the static type that the expression is expected to have. This is called the contextually expected type. For example, if a variable is declared by a type descriptor TD, then TD will be the contextually expected type for the expression initializing the variable. A type descriptor must be resolved before it can be used to provide a contextually expected type.

Many kinds of expression that construct values use the contextually expected type to determine the type of value constructed, rather than requiring the type to be specified explicitly. For each such kind of expression, there is a set of basic types (most often consisting of a single basic type) that the value constructed by that kind of expression will always belong to. In this case, the contextually expected type is narrowed by intersecting it with this set of basic types; this narrowed type is called the applicable contextually expected type. The narrowing is performed on the type descriptor by first normalizing the type descriptor into a union, where each member of the union is not a union and describes shapes from a single basic type, and then eliminating any members of the union with the wrong basic type; if this leaves no members, then it is a compile-time error; if it leaves a single member of the union, then the the applicable contextually expected type is this single member, otherwise it is a union of the remaining members.

Note the language provides a way to say that the type of a variable is to be inferred from the static type of the expression used to initialize the variable. In this case, there is no contextually expected type for the evaluation of the expression. Not having a contextually expected type is different from having a contextually expected type that allows all values.

6.2.3 Precise and broad types

There is an additional complexity relating to inferring types. Expressions in fact have two static types, a precise type and a broad type. Usually, the precise type is used. However, in a few situations, using the precise type would be inconvenient, and so Ballerina uses the broad type. In particular, the broad type is used for inferring the type of an implicitly typed non-final variable. Similarly, the broad type is used when it is necessary to infer the member type of the inherent type of a container.

In most cases, the precise type and the broad type of an expression are the same. For a compound expression, the broad type of an expression is computed from the broad type of the sub-expressions in the same way as the precise type of the expression is computed from the precise type of sub-expressions. Therefore in most cases, there is no need to mention the distinction between precise and broad types.

The most important case where the precise type and the broad type are different is literals. The precise type is a singleton type containing just the shape of the value that the literal represents, whereas the broad type is the precise type widened to contain the entire basic type of which it is a subtype. For example, the precise type of the string literal "X" is the singleton type "X", but the broad type is string.

For a type-cast-expr, the precise type and the broad type are the type specified in the cast.

6.3 Casting and conversion

Ballerina makes a sharp distinction between type conversion and type casting.

Casting a value does not change the value. Any value always belongs to multiple types. Casting means taking a value that is statically known to be of one type, and using it in a context that requires another type; casting checks that the value is of that other type, but does not change the value.

Conversion is a process that takes as input a value of one type and produces as output a possibly distinct value of another type. Note that conversion does not mutate the input value.

Ballerina always requires programmers to make conversions explicit, even between different types of number; there are no implicit conversions.

6.4 Constant expressions

const-expr := 
   literal
   | list-constructor-expr
   | mapping-constructor-expr
   | table-constructor-expr
   | string-template-expr
   | xml-expr
   | constant-reference-expr
   | type-cast-expr
   | unary-expr
   | multiplicative-expr
   | additive-expr
   | shift-expr
   | range-expr
   | numerical-comparison-expr
   | is-expr
   | equality-expr
   | binary-bitwise-expr
   | logical-expr
   | conditional-expr
   | ( const-expr )

Within a const-expr, any nested expression must also be a const-expr.

constant-reference-expr := variable-reference-expr

A constant-reference-expr must reference a constant defined with module-const-decl.

A const-expr is evaluated at compile-time. Constructors called within a const-expr construct their values as immutable. Note that the syntax of const-expr does not allow for the construction of error values. The result of a const-expr is always immutable.

simple-const-expr :=
  nil-literal
  | boolean-literal
  | [Sign] int-literal
  | [Sign] floating-point-literal
  | string-literal
  | constant-reference-expr

A simple-const-expr is a restricted form of const-expr used in contexts where various forms of constructor expression would not make sense. Its semantics are the same as a const-expr.

6.5 Literals

literal :=
   nil-literal
   | boolean-literal
   | numeric-literal
   | string-literal
   | byte-array-literal
numeric-literal := int-literal | floating-point-literal

A numeric-literal represents a value belonging to one of the basic types int, float or decimal. The basic type to which the value belongs is determined as follows:

if the numeric-literal includes a FloatTypeSuffix, then the basic type is float;
if the numeric-literal includes a DecimalTypeSuffix, then the basic type is decimal;
if the numeric-literal is a HexFloatingPointLiteral, then the basic type is float;
otherwise, the basic type depends on the applicable expected numeric type (where the possible basic types are int, float and decimal):
- if the applicable contextually expected type is a subtype of decimal, then the basic type is decimal;
- if the applicable contextually expected type is a subtype of float, then the basic type is float;
- otherwise, if the numeric literal is an int-literal, then the basic type is int;
- otherwise, the basic type is float.

The precise type of a numeric-literal is the singleton type containing just the shape of the value that the numeric-literal represents. The broad type is the basic type of which the precise type is a subset.

byte-array-literal := Base16Literal | Base64Literal
Base16Literal := base16 WS ` HexGroup* WS `
HexGroup := WS HexDigit WS HexDigit
Base64Literal := base64 WS ` Base64Group* [PaddedBase64Group] WS `
Base64Group :=
   WS Base64Char WS Base64Char WS Base64Char WS Base64Char
PaddedBase64Group :=
   WS Base64Char WS Base64Char WS Base64Char WS PaddingChar
   | WS Base64Char WS Base64Char WS PaddingChar WS PaddingChar
Base64Char := A .. Z | a .. z | 0 .. 9 | + | /
PaddingChar := =
WS := WhiteSpaceChar*

The static type of byte-array-literal is byte[N], where N is the number of bytes encoded by the Base16Literal or Base64Literal. The inherent type of the array value created is also byte[N].

6.6 List constructor

list-constructor-expr := [ [ expr-list ] ]
expr-list := expression (, expression)*

Creates a new list value. The members of the list come from evaluating each expression in the expr-list in order.

If there is a contextually expected type, then the inherent type of the newly created list is derived from the applicable contextually expected type. If the applicable contextually expected type is a list type descriptor, then that used as the inherent type. If the applicable contextually expected type is a union type descriptor, then any members of the union that do not contain list shapes of length N will be ignored, where N is the number of expressions in the expr-list; it is a compile-time error if this does not leave a single list type descriptor, which is then used as the inherent type. The static type of the list-constructor-expr will be the same as the inherent type.

If there is no contextually expected type, then the inherent type will be T[], where T is the union of the broad types of the expressions in expr-list. It is an compile-time error if expr-list is empty and there is no contextually expected type.

If there is a contextually expected type, then the type that the inherent type requires for each list member provides the contextually expected type for the expression for the member; otherwise there is no contextually expected type for the expressions for members.

A member of a list can be filled in automatically if the FillMember abstract operation would succeed on it. The inherent type of a list establishes either a fixed length for the list or just a minimum length for the list, which may be zero. In the latter case, a list constructor may specify only the first k members, provided that for each i from k + 1 up to the fixed length of the list, the i-th member can be filled in automatically.

6.7 Mapping constructor

mapping-constructor-expr := { [field (, field)*] }
field := (literal-field-name | computed-field-name) : value-expr
literal-field-name := field-name | string-literal
computed-field-name := [ expression ]
value-expr := expression

A mapping-constructor-expr creates a new mapping value.

If there is a contextually expected type, then the inherent type of the newly created mapping is derived from the applicable contextually expected type. If the applicable contextually expected type is a mapping type descriptor, then that used as the inherent type. If the applicable contextually expected type is a union type descriptor, then any members of the union that are inconsistent with the field names specified as a literal-field-name in the mapping-constructor-expr will be ignored; it is a compile-time error if this does not leave a single mapping type descriptor, which is then used as the inherent type. The static type of the mapping-constructor-expr will be the same as the inherent type.

If there is no contextually expected type, then the inherent type will be map<T>, where T is the union of the broad type of every value-expr in the mapping-constructor-expr. It is an compile-time error if there is both no value-expr and no contextually expected type.

If the inherent type descriptor is a record type descriptor and a field is specified using a field-name rather than a string-literal or expression, then the record type descriptor must include that field-name as an individual-type-descriptor.

If the inherent type descriptor is a record type descriptor, a field will be added to the constructed value using the default value from the type descriptor for any field that is not specified explicitly in the mapping constructor and that has a default value.

If there is a contextually expected type, then the type that the inherent type requires for each field provides the contextually expected type for the value-expr for that field; otherwise there is no contextually expected type for the value-expr forfields. The contextually expected type for a computed-field-name is string.

A field can have a computed field name, where the name of the field is specified by an expression enclosed in square brackets. A mapping-constructor-expr first constructs a mapping value without considering any fields with a computed field name. The effect of a field with a computed fieldname is to modify the member of the mapping with that name after the mapping has been constructed. If the modification is incompatible with the inherent type, then the mapping-constructor-expr will panic. The modifications are performed in the order in which the fields with computed field names occur in the mapping-constructor-expr.

6.8 [Preview] Table constructor

table-constructor-expr :=
   table { [column-descriptors [, table-rows]] }
column-descriptors := { column-descriptor (, column-descriptor)* }
column-descriptor := column-constraint* column-name
column-constraint :=
   key
   | unique
   | auto auto-kind 
auto-kind := auto-kind-increment
auto-kind-increment := increment [(seed, increment)]
seed := int-const-expr
increment := int-const-expr
int-const-expr := [Sign] int-literal
table-rows :=  [ table-row (, table-row)* ]
table-row := { expression (, expression)* }

The contextually expected type of the table-constructor-expr determines the inherent type of the constructed value.

For example,

table {
  { key firstName, key lastName, position },
  [ 
    {"Sanjiva", "Weerawarana", "lead" },
    {"James", "Clark", "design co-lead" }
  ]
}

6.9 Service constructor

service-constructor-expr := [annots] service service-body-block
service-body-block := { service-method-defn* }
service-method-defn :=
   metadata
   [resource]
   function identifier function-signature method-body

A service-constructor-expr constructs a service value. The result of evaluating a service-constructor-expr is a value of type service. If a service-method-defn contains a resource qualifier, then it defines a resource method. The self variable can be used in a method-body of a service-method-defn in the same way as for objects.

Each service value has a distinct type descriptor. (Evaluating a service constructor thus has an effect analogous to defining an anonymous object type and then creating a value of that type.)

The return type of a resource method must be a subtype of error? and must contain nil.

6.10 String template expression

string-template-expr := string BacktickString
BacktickString :=
  ` BacktickItem* Dollar* `
BacktickItem :=
   BacktickSafeChar
   | BacktickDollarsSafeChar
   | Dollar* interpolation
interpolation := ${ expression }
BacktickSafeChar := ^ ( ` | $ )
BacktickDollarsSafeChar :=  $+ ^ ( { | ` | $)
Dollar := $

A string-template-expr interpolates the results of evaluating expressions into a literal string. The static type of the expression in each interpolation must be a simple type and must not be nil. Within a BacktickString, every character that is not part of an interpolation is interpreted as a literal character. A string-template-expr is evaluated by evaluating the expression in each interpolation in the order in which they occur, and converting the result of the each evaluation to a string as if using by toString function of the lang.value module of the lang library. The result of evaluating the string-template-expr is a string comprising the literal characters and the results of evaluating and converting the interpolations, in the order in which they occur in the BacktickString.

A literal ` can be included in string template by using an interpolation ${"`"}.

6.11 [Preview] XML expression

xml-expr := xml BacktickString

An XML expression creates an XML value as follows:

The backtick string is parsed to produce a string of literal characters with interpolated expressions
The result of the previous step is parsed as XML content. More precisely, it is parsed using the production content in the W3C XML Recommendation. For the purposes of parsing as XML, each interpolated expression is interpreted as if it were an additional character allowed by the CharData and AttValue productions but no other. The result of this step is an XML Infoset consisting of an ordered list of information items such as could occur as the [children] property of an element information item, except that interpolated expressions may occur as Character Information Item or in the [normalized value] of an Attribute Information Item. Interpolated expressions are not allowed in the value of a namespace attribute.
This infoset is then converted to an XML value, together with an ordered list of interpolated expressions, and for each interpolated expression a position within the XML value at which the value of the expression is to be inserted.
The static type of an expression occurring in an attribute value must be a simple type and must not be nil. The static type type of an expression occurring in content can either be xml or a non-nil simple type.
When the xml-expr is evaluated, the interpolated expressions are evaluated in the order in which they occur in the BacktickString, and converted to strings if necessary. A new copy is made of the XML value and the result of the expression evaluations are inserted into the corresponding position in the newly created XML value. This XML value is the result of the evaluation.

6.12 New expression

new-expr := explicit-new-expr | implicit-new-expr
explicit-new-expr := new type-descriptor ( arg-list )

A new-expr constructs a new object.

An explicit-new-expr allocates storage for the object and initializes it, passing the supplied arg-list to the object's __init method. It is a compile error if the type-descriptor does not specify an object type or if the arg-list does not match the signature of the object type's __init method. If the result of calling the __init method is an error value e, then the result of evaluating the explicit-new-expr is e; otherwise the result is the newly initialized object.

An explicit-type-expr specifying a type descriptor T has static type T, except that if the type of the __init method is E?, where E is a subtype of error, then it has static type T|E.

implicit-new-expr := new [( arg-list )]

An implicit-new-expr is equivalent to an explicit-new-expr that specifies the applicable contextually expected type as the type descriptor. An implicit-new-expr consisting of just new is equivalent to new().

6.13 Variable reference expression

variable-reference-expr := variable-reference
variable-reference := identifier | qualified-identifier

A variable-reference can refer to a variable, a parameter, a constant (defined with a module constant declaration), a function or a type (defined with a type definition).

If the variable-reference references a type defined with a type definition, then the result of evaluating the variable-reference-expr is a typedesc value for that type.

6.14 Field access expression

field-access-expr := expression . field-name

A field-access-expr accesses a field of an object or a member of a mapping. The semantics depends on the static type T of expression.

If T is a subtype of the object basic type, then T must have a field field-name and the static type of the field-access-expr is the type of that field. In this case, the field-access-expr is evaluated by first evaluating the expression to get a value obj; the result of the field-access-expr is the value of that field of obj. The rest of this subsection applies when T is not a subtype of the object basic type.

Let T' be the intersection of T and basic type list, let K be the singleton type containing just the string field-name, and let M be the member type for K in T'. The compile-time requirements on the field-access-expr depend on whether the type descriptor describing T is lax:

if it is lax, then the only compile-time requirement is M is non-empty;
if it is not lax, then T must be a subtype of the mapping basic type and K must be a required key type for T.

The static type of field-access-expr is M|E, where E is empty if K is a required key type and T' is a subtype of T, and error otherwise (E can only be error in the lax case.) In the lax case, if M is lax, then the static type of the field-access-expr is lax even if E is an error.

A field-access-expr is evaluated as follows:

expression is evaluated resulting in a value v
if v has basic type error, the result is v (this can only happen in the lax case)
otherwise, if v does not have basic type mapping, the result is a new error value (this can only happen in the lax case)
otherwise, if v does not have a member whose key is field-name, the result is a new error value (this can only happen in the lax case)
otherwise, the result is the member of v whose key is field-name.

6.15 Optional field access expression

optional-field-access-expr := expression ?. field-name

An optional-field-access-expr accesses a possibly undefined mapping member, returning () if the member does not exist.

Let T be the static type of expression, let T' be the intersection of T and basic type list, let K be the singleton type containing just the string field-name and let M be the member type of K in T'. The compile-time requirements on the optional-field-access-expr depend on whether the type descriptor describing T is lax:

if it is lax, then the only compile-time requirement is that M is non-empty;
if it is not lax, then, in addition, T must be a subtype of the union of () and the mapping basic type, and the type descriptor for T must include field-name as an individual-type-descriptor (if the type descriptor is a union, then this requirement must be satisfied by at least one member of the union).

The static type of the optional-field-access-expr is M|N|E where

N is () if () is a subtype of T or K is not a required key type for T', and empty otherwise;
E is error if T' is not a subtype of T?, and empty otherwise (E can only be error in the lax case).

An optional-field-access-expr is evaluated as follows:

expression is evaluated resulting in a value v
if v is (), the result is ()
otherwise, if v has basic type error, the result is v (this can only happen in the lax case)
otherwise, if v does not have basic type mapping, the result is a new error value (this can only happen in the lax case)
otherwise, if v does not have a member whose key is field-name, the result is ()
otherwise, the result is the member of v whose key is field-name.

6.16 Annotation access expression

annot-access-expr := expression .@ annot-tag-reference

The annot-tag-reference must refer to an annotation tag0 declared with an annotation declaration. The static type of expression must be a subtype of typedesc.

An annot-access-expr is evaluated by first evaluating expression resulting in a typedesc value t. If t has an annotation with the tag referenced by annot-tag-reference, then the result of the annot-access-expr is the value of that annotation; otherwise, the result is nil.

The static type of the annot-access-expr is T? where T is the type of the annotation tag.

6.17 Member access expression

member-access-expr := container-expression [ key-expression ]
container-expression := expression
key-expression := expression

A member-access-expr accesses a member of a container value using its key, or a character of a string using its index.

The requirements on the static type of container-expr and key-expression are as follows:

if container-expr is a subtype of string or is a subtype of basic type list, then the contextually expected type for key-expression is int and the static type of key-expression must be a subtype of int;
otherwise container-expr must be a subtype of the union of nil and basic type list; in this case the contextually expected type for key-expression is string and the static type of key-expression must be a subtype of string.

A member-access-expr is evaluated as follows:

the container-expression is evaluated to get a value c;
the key-expression is evaluated to get a value k;
depending on the basic type of c
- if it is string, and k is < 0 or >= the length of c, then the evaluation completes abruptly with a panic; otherwise, the result is a string of length 1 containing the character with index k in c;
- if it is list, and k is < 0 or >= the length of c, then the evaluation completes abruptly with a panic; otherwise, the result is the member of c with index k;
- if it is mapping, then if c is () or c does not contain a member with key k, then the result is (); otherwise, the result is the member of c with key k.

Let T the static type of container-expression. If T is a subtype of string, then the static type of the member-access-expr is string. Otherwise, let K be the static type of key-expression and let M be the member type of K in T; if T contains nil, or T is a subtype of mapping and K is an optional key type for T, then the static type of the member-access-expr is M?, otherwise the static type is M.

6.18 [Preview] XML attributes expression

xml-attributes-expr := expression @

Returns the attributes map of a singleton xml value, or nil if the operand is not a singleton xml value. The result type is map<string>?.

6.19 Function call expression

function-call-expr := function-reference ( arg-list )
function-reference := variable-reference
arg-list :=
   positional-args [, other-args]
   | [other-args]
positional-args := positional-arg (, positional-arg)*
positional-arg := expression
other-args := named-args | rest-arg
named-args := named-arg (, named-arg)*
named-arg := arg-name = expression
arg-name := identifier
rest-arg := ... expression

A function-call-expr is evaluated by constructing an argument list and passing the argument list to the function referred to by the variable-name. If the function terminates normally, then the result of the function-call-expr is the return value of the function; otherwise the function-call-expr completes abruptly with a panic. The static type of the function-call-expr is the return type of the function type.

The variable-reference must refer to a variable with function type. The type descriptor of that function type is used to construct an argument list from the specified arg-list. Note that it is the type descriptor of the declared type of the variable that is used for this purpose, rather than the runtime type descriptor of the referenced function value.

The expressions occurring in the arg-list are evaluated in the order in which they occur in the arg-list. The result of evaluating each positional-arg is added to the argument list in order. The contextually expected type for the expression in the i-th positional-arg is the type of the i-th parameter.

If there is a rest-arg, then it is evaluated. The result must be a list value. Each member of the list value is added to the argument in the order that it occurs. The static type of the list value must be such as to guarantee that the resulting argument list will conform to the function's declared param-list. The rest-arg is not restricted to supplying the part of the argument list that will be bound to a rest-param, and its static type is not restricted to being an array type. If there is rest-arg, then no parameter defaults are added.

If there is no rest-arg, then each non-rest parameter that was not supplied by positional argument is added in order from a named argument, if there is one, and otherwise using the parameter default. An arg-list can only use a named argument to specify a parameter if the name of the parameter is visible at the point where the arg-list occurs. The contextually expected type for the expression specifying a named argument is the type declared for the corresponding parameter. A default parameter is computed by calling the closure in the type descriptor, passing it the previous arguments in the argument list. It is a compile-time error if there is a non-rest parameter for which there was no positional argument and no named argument and which is not defaultable. It is also an error if there is a named argument for a parameter that was supplied by a positional argument.

When a function to be called results from the evaluation of an expression that is not merely a variable reference, the function can be called by first storing the value of the expression in a variable.

6.20 Method call expression

method-call-expr := expression . method-name ( arg-list )

A method-call-expr either calls a method or calls a function in the lang library. The evaluation of the method-call-expr starts by evaluating expression resulting in some value v. There is no contextually expected type for expression.

If the static type of expression is a subtype of object, and the object type includes a method named method-name, then the method-call-expr is executed by calling that method on v. A method-call-expr can be used within a method of a service to call another method of that service other than a resource method; in this case, expression must be self. The arg-list is used to construct an argument list that is passed to the method in the same way as with a function-call-expr. A method-call-expr cannot be used to call a remote method; it can only be called by a remote-method-call-action. A method-call-expr cannot be used to call a resource method.

Otherwise, the method-call-expr will be turned into a call to a function in the lang library m:method-name(expression, arg-list), where m is an automatically created module prefix for a module lang.M of the lang library, where M is selected as follows.

If the static type of expression is a subtype of some basic type with identifier B, and the module lang.B contains a function method-name then M is B. The identifier for a basic type is the reserved identifier used in type descriptors for subtypes of that basic type, as listed in the Lang library section.
Otherwise, M is value.

It is a compile-time error if the resulting function call does not satisfy all the constraints that would apply if it has been written explicitly as a function-call-expr.

6.21 Error constructor

error-constructor-expr := direct-error-constructor-expr | indirect-error-constructor-expr
direct-error-constructor-expr := error ( direct-error-arg-list )
indirect-error-constructor-expr := error-type-reference ( indirect-error-arg-list )
direct-error-arg-list := positional-arg (, named-arg)*
indirect-error-arg-list := [named-arg (, named-arg)*]

An error constructor constructs a new error value. There are two kinds of error constructor: direct and indirect. A direct error constructor specifies the error reason string as the first argument to the constructor. An indirect error constructor references an error type that determines the reason string.

The contextually expected type for the positional-arg in a direct-error-constructor-expr is string.

The error-type-reference in an indirect-error-constructor must refer to an identifier named by a type definition whose type descriptor is an error type descriptor, whose reason-type-descriptor is a singleton string. An indirect-error-constructor-expr ET(named-args) where ET refers to a type error<S,D>, where S is a singleton string, is equivalent to a direct-error-constructor-expr <ET>error(S, named-args).

Evaluating the error-constructor-expr creates a new detail mapping. Each named-arg specifies a field of the error detail mapping; the static type of each named-arg must be a pure type. If there is a contextually-expected-type for a direct-error-constructor-expr and the applicable contextually expected type is an error type descriptor (rather than a union) with detail type D, then the error detail mapping will also have a field for any defaultable fields of D for which no named-arg was specified. The contextually expected type for each named-arg is determined by the applicable contextually type in the same way as for a mapping-constructor-expr. The detail mapping for an indirect-error-constructor-expr is constructed as if by the equivalent direct-error-constructor-expr, and so in this case there will always be an applicable contextually expected type that is an error type descriptor. The detail mapping is constructed as immutable, with its members being the result of appplying the ImmutableClone abstract operation to the result of evaluating each named-arg and every defaultable arg.

The stack trace in the constructed error value describes the execution stack at the point where the error constructor was evaluated.

6.22 Anonymous function expression

anonymous-function-expr :=
  [annots] function function-signature function-body-block

Evaluating an anonymous-function-expr creates a closure, whose basic type is function. If function-body-block refers to a block-scope variable defined outside of the function-body-block, the closure will capture a reference to that variable; the captured reference will refer to the same storage as the original reference not a copy.

6.23 Arrow function expression

arrow-function-expr := arrow-param-list => expression
arrow-param-list :=
   identifier
   | ([identifier (, identifier)*])

Arrow functions provide a convenient alternative to anonymous function expressions that can be used for many simple cases. An arrow function can only be used in a context where a function type is expected. The types of the parameters are inferred from the expected function type. The scope of the parameters is expression. The static type of the arrow function expression will be a function type whose return type is the static type of expression. If the contextually expected type for the arrow-function-expr is a function type with return type T, then the contextually expected type for expression is T.

6.24 Type cast expression

type-cast-expr := < type-cast-param > expression
type-cast-param := [annots] type-descriptor | annots

Normally, the parameter for a type-cast-expr includes a type-descriptor. However, it is also allowed for the parameter to consist only of annotations; in this case, the only effect of the type cast is for the contextually expected type for expression to be augmented with the specified annotations. The rest of this subsection describes the normal case, where the type-cast-expr includes a type-descriptor.

A type-cast-expr casts the value resulting from evaluating expression to the type described by the type-descriptor, performing a numeric conversion if required.

A type-cast-expr is evaluated by first evaluating expression resulting in a value v. Let T be the type described by type-descriptor. If v belongs T, then the result of the type-cast-expr is v. Otherwise, if T includes shapes from exactly one basic numeric type N and v is belongs to another basic numeric type, then let n be NumericConvert(N, v); if n is not an error and n belongs to T, then the result of the type-cast-expr is n. Otherwise, the evaluation of the type-cast-expr completes abruptly with a panic.

Let T be the static type described by type-descriptor, and let TE be the static type of expression. Then the static type of the type-cast-expr is the intersection of T and TE', where TE' is TE with its numeric shapes transformed to take account to the possibility of the numeric conversion specified in the previous paragraph.

The type-descriptor provides the contextually expected type for expression.

6.25 Typeof expression

typeof-expr := typeof expression

The result of a typeof-expr is a typedesc value for the runtime type of v, where v is the result of evaluating expression.

The runtime type of v is the narrowest type to which v belongs.

When v is a simple value, the resulting typedesc will describe a type consisting of a single shape, which is the shape of the value. The typedesc will not have any annotations. Each evaluation of typeof with a simple value produces a new typedesc value.
When v is a reference value, each evaluation of typeof with an identical reference value produces an identical typedesc value. The type descriptor resulting from typeof will be the same as the type descriptor used to construct the value. For containers, this is the same as the inherent type; when the container is immutable, it will be a singleton type. For an object, this is the same as the type descriptor used with new. Any annotations that were attached to the type descriptor used to construct the value will this be available on the constructed value.

The static type of typeof-expr is typedesc<T>, where T is the static type of expression.

6.26 Unary expression

unary-expr :=
   + expression
   | - expression
   | ~ expression
   | ! expression

The unary - operator performs negation. The static type of the operand must be a number; the static type of the result is the same basic type as the static type of the operand. The semantics for each basic type are as follows:

int: negation for int is the same as subtraction from zero; a panic will occur on overflow, which happens when the operand is -2⁶³)
float, decimal: negation for floating point types corresponds to the negate operation as defined by IEEE 754-2008 (this is not the same as subtraction from zero);

If the contextually expected type for a - expression is T, then the contextualy expected type for the operand expressions is T', where a value v is in T' if it belongs to int, decimal or float, and T contains a value with the same basic type as v.

The unary + operator returns the value of its operand expression. The static type of the operand must be a number, and the static type of the result is the same as the static type of the operand expression.

The ~ operator inverts the bits of its operand expression. The static type of the operand must be int, and the static type of the result is an int.

The ! operator performs logical negation. The static type of the operand expression must be boolean. The ! operator returns true if its operand is false and false if its operand is true.

6.27 Multiplicative expression

multiplicative-expr :=
   expression * expression
   | expression / expression
   | expression % expression

The * operator performs multiplication; the / operator performs division; the % operator performs remainder.

The static type of both operand expressions is required to be a subtype of the same basic type; this basic type will be the static type of the result. The following basic types are allowed:

int
- * performs integer multiplication; a panic will occur on overflow
- / performs integer division, with any fractional part discarded ie with truncation towards zero; a panic will occur on division by zero or overflow, which happens if the first operand is -2⁶³ and the second operand is -1
- % performs integer remainder consistent with integer division, so that if x/y does not result in a panic, then (x/y)*y + (x%y) is equal to x; a panic will occur if the second operand is zero; if the first operand is -2⁶³ and the second operand is -1, then the result is 0
float, decimal
- * performs the multiplication operation with the destination format being the same as the source format, as defined by IEEE 754-2008; this never causes a panic to occur
- / performs the division operation with the destination format being the same as the source format, as defined by IEEE 754-2008; this never causes a panic to occur
- % performs a remainder operation; the remainder is not the IEEE-defined remainder operation but is instead a remainder operation analogous to integer remainder; more precisely,
  - if x is NaN or y is NaN or x is an infinity or y is a zero, then x % y is NaN
  - for finite x, and infinite y, x % y is x
  - for finite x and finite non-zero y, x % y is equal to the result of rounding x - (y × n) to the nearest representable value using the roundTiesToEven rounding mode, where n is the integer that is nearest to the mathematical quotient of x and y without exceeding it in magnitude; if the result is zero, then its sign is that of x
  - no exceptions are thrown

If the contextually expected type for a multiplicative-expr is T, then the contextualy expected type for both operand expressions is T', where a value v is in T' if it belongs to int, decimal or float, and T contains a value with the same basic type as v.

6.28 Additive expression

additive-expr :=
   expression + expression
   | expression - expression

The + operator is used for both addition and concatenation; the - operator is used for subtraction.

It is required that either

the static type of both operand expressions is a subtype of the same basic type, in which case this basic type will be the static type of the result, or
the static type of one operand expression must be a subtype of xml and of the other operand expression must be a subtype of string, in which case the static type of the result is xml

The semantics for each basic type is as follows:

int
- + performs integer addition; a panic will occur on overflow
- - performs integer subtraction; a panic will occur on overflow
float, decimal
- + performs the addition operation with the destination format being the same as the source format, as defined by IEEE 754-2008; this never causes a panic to occur
- - performs the subtraction operation with the destination format being the same as the source format, as defined by IEEE 754-2008; this never causes a panic to occur
string, xml
- if both operands are a string, then the result is a string that is the concatenation of the operands
- if both operands are xml, then the result is a new xml sequence that is the concatenation of the operands; the new xml sequence contains a shallow copy of both operands; this operation does not perform a copy of the content or attributes of any elements in sequence
- if one operand is a string and one is xml, the string is treated as if it were an xml sequence with one character item for each code point in the string

If the contextually expected type for a multiplicative-expr is T, then the contextualy expected type for both operand expressions is T', where a value v is in T' if it belongs to int, decimal, float, string or xml and T contains a value with the same basic type as v.

6.29 Shift expression

shift-expr :=
   expression << expression
   expression >> expression
   expression >>> expression

A shift-expr performs a bitwise shift. Both operand expressions must have static type that is a subtype of int. The left hand operand is the value to be shifted; the right hand value is the shift amount; all except the bottom 6 bits of the shift amount are masked out (as if by x & 0x3F). Then a bitwise shift is performed depending on the operator:

<< performs a left shift, the bits shifted in on the right are zero
>> performs a signed right shift; the bits shifted in on the left are the same as the most significant bit
>>> performs a unsigned right shift, the bits shifted in on the left are zero

If the operator is >> or >>> and the left hand operand is a subtype of byte, then the static type of the result is byte; otherwise the static type of the result is int.

6.30 Range expression

range-expr :=
   expression ... expression
   | expression ..< expression

The result of a range-expr is a new object belonging to the abstract object type Iterable<int> that will iterate over a sequence of integers in increasing order, where the sequence includes all integers n such that

the value of the first expression is less than or equal to n, and
n is
- if the operator is ..., less than or equal to the value of the second expression
- if the operator is ..<, less than the value of the second expression

It is a compile error if the static type of either expression is not a subtype of int.

A range-expr is designed to be used in a foreach statement, but it can be used elsewhere.

6.31 Numerical comparison expression

numerical-comparison-expr :=
   expression < expression
   | expression > expression
   | expression <= expression
   | expression >= expression

A numerical-comparison-expr compares two numbers.

The static type of both operands must be of the same basic type, which must be int, float or decimal. The static type of the result is boolean.

Floating point comparisons follow IEEE, 754-2008, so

if either operand is NaN, the result is false
positive and negative zero compare equal

6.32 Type test expression

is-expr :=
   expression is type-descriptor

An is-expr tests where a value belongs to a type.

An is-expr is evaluated by evaluating the expression yielding a result v. If v belongs to the type denoted by type-descriptor, then the result of the is-expr is true; otherwise the result of the is-expr is false.

6.33 Equality expression

equality-expr :=
   expression == expression
   | expression != expression
   | expression === expression
   | expression !== expression

An equality-expr tests whether two values are equal. For all four operators, it is a compile time error if the intersection of the static types of the operands is empty.

The === operator tests for exact equality. The !== operator results in the negation of the result of the === operator. Two values are exactly equal if they have the same basic type T and

if T is simple type, the values are identical values within the set of values allowed for T
if T is a reference type, the values refer to the same storage

The == operator tests for deep equality. The != operator results in the negation of the result of the == operator. For both == and !=, both operands must have a static type that is pure. Two values v1, v2 are deeply equal if SameShape(v1, v2) is true.

Note that === and == are the same for simple values except for floating point types.

For the float type, the operators differ as regards floating point zero: == treats positive and negative zero from the same basic type as equal whereas === treats them as unequal. Both == and === treat two NaN values from the same basic type as equal. This means that neither of these operators correspond to operations defined by IEEE 754-2008, because they do not treat NaN in the special way defined for those operations.

For the decimal type, the operators differ in whether they consider the precision of the value. For example, 1.0 == 1.00 is true but 1.0 === 1.00 is false.

6.34 Binary bitwise expression

binary-bitwise-expr :=
   bitwise-and-expr
   | bitwise-xor-expr
   | bitwise-or-expr
bitwise-and-expr := expression & expression
bitwise-xor-expr := expression ^ expression
bitwise-or-expr := expression | expression

A binary-bitwise-expr does a bitwise AND, XOR, or OR operation on its operands.

The static type of both operands must be a subtype of int. The static type of the result is as follows:

for AND, if the type of one operand is a subtype of byte, then the result has type byte; otherwise, the result has type int;
for XOR or OR, if the type of both operands have a type that is a subtype of byte, then the result has type byte; otherwise, the result has type int.

6.35 Logical expression

logical-expr := logical-and-expr | logical-or-expr
logical-and-expr := expression && expression
logical-or-expr := expression || expression

The static type of each expression in a logical-expr must be a subtype of boolean.

A logical-and-expr is evaluated as follows:

the left-hand expression is evaluated, resulting in a value x;
if x is false, then the result of the logical-and-expr is x, and the right-hand expression is not evaluated;
otherwise, the result of the logical-and-expr is the result of evaluating the right-hand expression.

A logical-or-expr is evaluated as follows:

the left-hand expression is evaluated, resulting in a value x;
if x is true, then the result of the logical-or-expr is x, and the right-hand expression is not evaluated;
otherwise, the result of the logical-or-expr is the result of evaluating the right-hand expression.

6.36 Conditional expression

conditional-expr :=
   expression ? expression : expression
   | expression ?: expression

L ?: R is evaluated as follows:

Evaluate L to get a value x
If x is not nil, then return x.
Otherwise, return the result of evaluating R.

6.37 Checking expression

checking-expr := checking-keyword expression
checking-keyword := check | checkpanic

Evaluates expression resulting in value v. If v has basic type error, then

if the checking-keyword is check, then the check-expression completes abruptly with a check-fail with associated value v;
if the checking-keyword is checkpanic, then the check-expression completes abruptly with a panic with associated value v.

If the static type of expression e is T|E, where E is a subtype of error, then the static type of check e is T.

6.38 Trap expression

The trap expression stops a panic and gives access to the error value associated with the panic.

trap-expr := trap expression

Semantics are:

Evaluate expression resulting in value v
- If evaluation completes abruptly with panic with associated value e, then result of trap-exp is e
- Otherwise result of trap-expr is v
If type of expr is T, then type of trap expr is T|error.

7. Actions and statements

7.1 Actions

action :=
   start-action
   | wait-action
   | send-action
   | receive-action 
   | flush-action
   | remote-method-call-action
   | checking-action
   | trap-action
   | ( action )
action-or-expr := action | expression
checking-action := checking-keyword action
trap-action := trap action

Actions are an intermediate syntactic category between expressions and statements. Actions are similar to expressions, in that they yield a value. However, an action cannot be nested inside an expression; it can only occur as part of a statement or nested inside other actions. This is because actions are shown in the sequence diagram in the graphical syntax.

An action is evaluated in the same way as an expression. Static typing for actions is the same as for expressions.

A checking-action and trap-action is evaluated in the same way as a checking-expr and trap-expr respectively.

7.2 Threads and strands

Ballerina's concurrency model supports both threads and coroutines. A Ballerina program is executed on one or more threads. A thread may run on a separate core simultaneously with other threads, or may be pre-emptively multitasked with other threads onto a single core.

Each thread is divided into one or more strands. No two strands belonging to the same thread can run simultaneously. Instead, all the strands belonging to a particular thread are cooperatively multitasked. Strands within the same thread thus behave as coroutines relative to each other. A strand enables cooeperative multitasking by yielding. When a strand yields, the runtime scheduler may suspend execution of the strand, and switch its thread to executing another strand. The following actions cause a strand to yield:

worker-receive-action
wait-action
flush-action
sync-send-action

In addition, any function with an external-function-body can potentially yield; it should only do so if it performs a system call that would block. or calls a Ballerina function that itself yields. Functions in the lang library do not themselves yield, although if they call a function passed as an argument, that function may result in yielding.

There are two language constructs whose execution causes the creation of new strands: named-worker-decl and start-action. These constructs may use annotations to indicate that the newly created strand should be in a separate thread from the current strand. In the absence of such annotations, the new strand must be part of the same thread as the current strand.

7.3 Function and worker execution

function-body-block :=
   { [default-worker-init named-worker-decl+] default-worker }
default-worker-init := sequence-stmt
default-worker := sequence-stmt
named-worker-decl :=
   [annots] worker worker-name return-type-descriptor { sequence-stmt }
worker-name := identifier

A worker represents a single strand of a function invocation. A statement is always executed in the context of a current worker. A worker is in one of three states: active, inactive or terminated. When a worker is in the terminated state, it has a termination value. A worker terminates either normally or abnormally. An abnormal termination results from a panic, and in this case the termination value is always an error. If the termination value of a normal termination is an error, then the worker is said to have terminated with failure; otherwise the worker is said to have terminated with success. Note that an error termination value resulting from a normal termination is distinguished from an error termination value resulting from an abnormal termination.

A function always has a single default worker, which is unnamed. The strand for the default worker is the same as the strand of the worker on which function was called. When a function is called, the current worker becomes inactive, and a default worker for the called function is started. When the default worker terminates, the function returns to its caller, and the caller's worker is reactivated. Thus only one worker in each strand is active at any given time. If the default worker terminates normally, then its termination value provides the return value of the function. If the default worker terminates abnormally, then the evaluation of the function call expression completes abruptly with a panic and the default worker's termination value provides the associated value for the abrupt completion of the function call. The function's return type is the same as the return type of the function's default worker.

A function also has zero or more named workers. Each named worker runs on its own new strand. The termination of a function is independent of the termination of its named workers. The termination of a named worker does not automatically result in the termination of its function. When a default worker terminates causing the function to terminate, the function does not automatically wait for the termination of its named workers.

A named worker has a return type. If the worker terminates normally, the termination value will belong to the return type. If the return type of a worker is not specified, it defaults to nil as for functions. A return-type-descriptor in a named-worker-decl is an inferable context for a type descriptor, which means that * can be used to infer parts of the type descriptor; in particular, it is convenient to use error<*> to specify the error type.

When a function has named workers, the default worker executes in three stages, as follows:

The statements in default-worker-init are executed.
All the named workers are started. Each named worker executes its sequence-stmt on its strand.
The statements in default-worker are executed. This happens without waiting for the termination of the named workers started in stage 2.

Variables declared in default-worker-init are in scope within named workers, whereas variables declared in default-worker are not.

The execution of a worker's sequence-stmt may result in the execution of a statement that causes the worker to terminate. For example, a return statement causes the worker to terminate. If this does not happen, then the worker terminates as soon as it has finished executing its sequence-stmt. In this case, the worker terminates normally, and the termination value is nil. In other words, falling off the end of a worker is equivalent to return;, which is in turn equivalent to return ();.

The parameters declared for a function are in scope in the function-body-block. They are implicitly final: they can be read but not modified. They are in scope for named workers as well as for the default worker.

The scope of a worker-name in a named-worker-decl that is part of a function-body-block is the entire function-body-block with the exception of the default-worker-init. When a worker-name is in scope, it can be used in a variable-reference-expr. The result of evaluating such a variable reference is a future value that refers to the value to be returned by that named worker. The static type of the result is future<T>, where T is the return type of the worker.

A strand can initiate a wait on another strand by using a wait-action with a value of type future. Only one wait on a strand can succeed; this wait receives the value returned by the strand. Any other waits on that strand fail. It is a compile-time error if for any named worker it is possible for the name of that worker to be evaluated as a variable-reference more than once for any execution of that worker. This ensures that wait operations that use just a worker-name to identify the strand to wait on cannot fail at runtime.

In the above, function includes method, and function call includes method call.

7.4 Statement execution

statement := 
   action-stmt
   | block-stmt
   | local-var-decl-stmt
   | local-type-defn-stmt
   | xmlns-decl-stmt
   | assignment-stmt
   | compound-assignment-stmt
   | destructuring-assignment-stmt
   | call-stmt
   | if-else-stmt
   | match-stmt
   | foreach-stmt
   | while-stmt
   | break-stmt
   | continue-stmt
   | fork-stmt
   | panic-stmt
   | return-stmt

The execution of any statement may involve the evaluation of actions and expressions, and the execution of substatements. The following sections describes how each kind of statement is evaluated, assuming that the evaluation of those expressions and actions completes normally, and assuming that the execution of any substatements does not cause termination of the current worker. Except where explicitly stated to the contrary, statements handle abrupt completion of the evaluation of expressions and actions as follows. If in the course of executing a statement, the evaluation of some expression or action completes abruptly with associated value e, then the current worker is terminated with termination value e; if the abrupt termination is a check-fail, then the termination is normal, otherwise the termination is abnormal. If the execution of a substatement causes termination of the current worker, then the execution of the statement terminates at that point.

sequence-stmt := statement*
block-stmt := { sequence-stmt }

A sequence-stmt executes its statements sequentially. A block-stmt is executed by executing its sequence-stmt.

7.5 Fork statement

fork-stmt := fork { named-worker-decl+ }

The fork statement starts one or more named workers, which run in parallel with each other, each in its own new strand.

Variables and parameters in scope for the fork-stmt remain in scope within the workers (similar to the situation with parameters and workers in a function body).

The scope of the worker-name in a named-worker-decl that is part of a fork-stmt consists of both other workers in the same fork-stmt and the block containing the fork-stmt starting from the point immediately after the fork-stmt. Within its scope, the worker-name can be used in a variable-reference-expr in the same way as the worker-name of a named-worker-decl that is part of a function-body-block.

7.6 Start action

start-action := [annots] start (function-call-expr|method-call-expr|remote-method-call-action)

The keyword start causes the following function or method invocation to be executed on a new strand. The arguments for the function or method call are evaluation on the current strand. A start-action returns a value of basic type future immediately. If the static type of the call expression or action C is T, then the static type of start C is future<T>.

7.7 Wait action

A wait-action waits for one or more strands to terminate, and gives access to their termination values.

wait-action :=
   single-wait-action
   | multiple-wait-action
   | alternate-wait-action

wait-future-expr := expression but not mapping-constructor-expr

A wait-future-expr is used by a wait-action to refer to the worker to be waited for. Its static type must be future<T> for some T. As elsewhere, a wait-future-expr can use an in-scope worker-name in a variable-reference-expr to refer to named worker.

Evaluation of a wait-action performs a wait operation on the future value that results from evaluating a wait-future-expr. This wait operation may complete normally or abruptly. The wait operation initiates a wait for the strand that the future refers to. If the wait fails, then the wait operation completes normally and the result is an error. If the wait succeeds, and the strand completed normally, then the wait operation completes normally, and the result is the termination value of the strand. If the wait succeeds, but the strand completed abnormally, then the wait operation completes abruptly with a panic and the associated value is the termination value of the strand.

In addition to a static type, a wait-future-expr has a compile-time eventual type. If a wait-future-expr is a variable-reference-expr referring to the worker-name of a named worker with return type T, then the eventual type of the wait-future-expr is T. Otherwise, the eventual of a wait-future-expr with static type future<T> is T|error. The result of a wait operation that completes normally will belong to the eventual type of the wait-future-expr, since the compiler ensures that a wait for a wait-future-expr that is a variable reference to a named worker cannot fail.

Note that it is only possible to wait for a named worker, which will start its own strand. It is not possible to wait for a default worker, which runs on an existing strand.

A mapping-constructor-expr is not recognized as a wait-future-expr (it would not type-check in any case).

7.7.1 Single wait action

single-wait-action := wait wait-future-expr

A single-wait-action waits for a single future.

A single-wait-action is evaluated by first evaluating wait-future-expr resulting in a value f of basic type future; the single-wait-action then performs a wait operation on f.

The static type of the single-wait-action is the eventual type of the wait-future-expr.

7.7.2 Multiple wait action

multiple-wait-action := wait { wait-field (, wait-field)* }
wait-field :=
  variable-name
  | field-name : wait-future-expr

A multiple-wait-action waits for multiple futures, returning the result as a record.

A wait-field that is a variable-name v is equivalent to a wait-field v: v, where v must be the name of an in-scope named worker.

A multiple-wait-action is evaluated by evaluating each wait-future-expr resulting in a value of type future for each wait-field. The multiple-wait-action then performs a wait operation on all of these futures. If all the wait operations complete normally, then it constructs a record with a field for each wait-field, whose name is the field-name and whose value is the result of the wait operation. If any of the wait operations complete abruptly, then the multiple-wait-action completes abruptly.

The static type of the multiple-wait-action is a record where the static type of each field is the eventual type of the corresponding wait-future-expr.

7.7.3 Alternate wait action

alternate-wait-action := wait wait-future-expr (| wait-future-expr)+

An alternate-wait-action waits for one of multiple futures to terminate.

An alternate-wait-action is evaluated by first evaluating each wait-future-expr, resulting in a set of future values. The alternate-wait-action then performs a wait operation on all of these members of this set. As soon as one of the wait operations completes normally with a non-error value v, the alternate-wait-action completes normally with result v. If all of the wait operations complete normally with an error, then it completes normally with result e, where e is the result of the last wait operation to complete. If any of the wait operations completely abruptly before the alternate-wait-action completes, then the alternate-wait-action completes abruptly.

The static type of the alternate-wait-action is the union of the eventual type of all of its wait-future-exprs.

7.8 Worker message passing

Messages can be sent between workers.

Sends and receives are matched up at compile-time. This allows the connection between the send and the receive to be shown in the sequence diagram. It is also guarantees that any sent message will be received, provided that neither the sending nor the receiving worker terminate abnormally or with an error.

Messages can only be sent between workers that are peers of each other. The default worker and the named workers in a function are peers of each other. The workers created in a fork-stmt are also peers of each other. The workers created in a fork-stmt are not peers of the default worker and named workers created by a function.

peer-worker := worker-name | default

A worker-name refers to a worker named in a named-worker-decl, which must be in scope; default refers to the default worker. The referenced worker must be a peer worker.

Each worker maintains a separate logical queue for each peer worker to which it sends messages; a sending worker sends a message by adding it to the queue; a receiving worker receives a message by removing it from the sending worker's queue for that worker; messages are removed in the order in which they were added to the queue.

7.8.1 Send action and send statement

send-action := sync-send-action | async-send-action
sync-send-action := expression ->> peer-worker
async-send-action := expression -> peer-worker ;

A send-action sends a message to the worker that is identified by peer-worker. A send-action starts by evaluating the expression, resulting in a value v; the Clone abstract operation to v resulting in value c. This value c is added to the message queue maintained by the sending worker for messages to be sent to the sending worker;this queue continues to exist even if the receiving worker has already terminated.

For each send-action S, the compiler determines a unique corresponding receive-action R, such that a message sent by S will be received by R, unless R's worker has terminated abnormally or with failure. It is a compile-time error if this cannot be done. The compiler determines a failure type for the corresponding receive-action. If the receive-action was not executed and its worker terminated normally, then the termination value of the worker will belong to the failure type. The failure type will be a (possibly empty) subtype of error.

The difference between async-send-action and sync-send-action is in what happens after the message is added to the queue. The evaluation of async-send-action completes immediately after this, and the result is always (). A subsequent flush action can be used to check whether the message was received. With sync-send-action, evaluation waits until the receiving worker either executes a receive action that receives the queued message or terminates. The evaluation of sync-send-action completes as follows:

if the queued message was received, then normally with result nil;
otherwise
- if the receiving worker terminated with failure, then normally with the result being the the termination value of the receiving worker, which will be an error;
- if the receiving worker terminated abnormally, then abruptly with a panic, with the associated value being the termination value of the receiving worker.

The static type of the sync-send-action is F|() where F is the failure type of the corresponding receive action. If F is empty, then this static type will be equivalent to ().

The contextually expected type used to interpret expression is the contextually expected type from the corresponding receive-action.

If the receive-action corresponding to an async-send-action has a non-empty failure type, then it is a compile-time error unless it can be determined that a sync-send-action or a flush-action will be executed before the sending worker terminates with success.

If a worker W is about to terminate normally and there are messages still to be sent in a queue (which must be the result of executing an async-send-action), then the worker waits until the messages have been received or some receiving worker terminates. If a receiving worker R terminates without the message being received, R must have terminated abnormally, because the rule in the preceding paragraph. In this case, W terminates abnormally and W will use R's termination value as its termination value.

7.8.2 Receive action

receive-action := single-receive-action | multiple-receive-action

7.8.2.1 Single receive action

single-receive-action := <- peer-worker

A single-receive-action receives a message from a single worker.

For each single-receive-action R receiving from worker W, the compiler determines a corresponding send set. The corresponding send set S is a set of send actions in W, such that

in any execution of W that terminates successfully, exactly one member of S is executed and is executed once only
if R is evaluated, it will receive the single message sent by a member of S, unless W has terminated abnormally or with failure.

The compiler terminates a failure type for the corresponding send set. If no member of the corresponding send set was evaluated and the sending worker terminated normally, then the termination value of the sending worker will belong to the failure type. The failure type will be a (possibly empty) subtype of error.

A single-receive-action is evaluated by waiting until there is a message available in the queue or the sending worker terminates. The evaluation of single-receive-action completes as follows:

if a message becomes available in the queue, then the first available message is removed and the evaluation completes normally with the result being that message;
otherwise
- if the sending worker terminated with failure, then normally with the result being the the termination value of the sending worker, which will be an error;
- if the sending worker terminated abnormally, then abruptly with a panic, with the associated value being the termination value of the sending worker.

The static type of the single-receive-action is T|F where T is the union of the static type of the expressions in the corresponding send set and F is the failure type of the corresponding send set.

7.8.2.2 Multiple receive action

multiple-receive-action :=
   <-  { receive-field (, receive-field)* }
receive-field :=
   peer-worker
   | field-name : peer-worker

A multiple-receive-action receives a message from multiple workers.

A peer-worker can occur at most once in a multiple-receive-action.

A receive-field consisting of a peer-worker W is equivalent to a field W:W.

The compiler determines a corresponding send set for each receive field, in the same way as for a single-receive-action. A multiple-receive-action is evaluated by waiting until there is a message available in the queue for every peer-worker. If any of the peer workers W terminate before a message becomes available, then the evaluation of the multiple-receive-action completes as follows

if the sending worker terminated with failure, then normally with the result being the the termination value of the sending worker, which will be an error;
if the sending worker terminated abnormally, then abruptly with a panic, with the associated value being the termination value of the sending worker.

Otherwise, the result of the evaluation of multiple-receive-action completes by removing the first message from each queue and constructing a record with one field for each receive-field, where the value of the record is the message received.

The contextually expected typed for the multiple-receive-action determines a contextually expected type for each receive-field, in the same way as for a mapping constructor. The contextually expected type for each receive-field provides the contextually expected type for the expression in each member of the corresponding send set.

The static type of multiple-receive-action is R|F where

R is a record type, where R is determined in the same way as for a mapping constructor, where the static type of each field comes from the union of the static types of the expressions in each member of the corresponding send set and the contextually expected type is the contextually expected type of the multiple-receive-action
F is the union of the failure types for the corresponding send set for each receive-field

7.8.3 Flush action

flush-action := flush [peer-worker]

If peer-worker is specified, then flush waits until the queue of messages to be received by peer-worker is empty or until the peer-worker terminates.

Send-receive correspondence for async-send-action implies that the queue will eventually become empty, unless the peer-worker terminates abnormally or with failure. The evaluation of flush-action completes as follows:

if the queue of messages is empty, then normally with result nil;
otherwise
- if the peer-worker terminated with failure, then normally with the result being the the termination value of the peer-worker, which will be an error;
- if the peer-worker terminated abnormally, then abruptly with a panic, with the associated value being the termination value of the peer-worker.

If the flush-action has a preceding async-send-action without any intervening sync-send-action or other flush-action, then the static type of the flush-action is F|(), where F is the failure type of the receive-action corresponding to that async-send-action. Otherwise, the static type of the flush-action is nil.

If peer-worker is omitted, then the flush-action flushes the queues to all other workers. In this case, the static type will be the union of the static type of flush on each worker separately.

7.8.4 Send-receive correspondence

This section provides further details about how compile-time correspondence is established between sends and receive. This is based on the concept of the index of a message in its queue: a message has index n in its queue if it is the nth message added to the queue during the current execution of the worker.

A send action/statement has index i in its queue if the message that it adds to the queue is always the i-th message added to the queue during the execution of its worker. It is a compile time error if a send statement or action does not have an index in its queue.
A receive action has index i in a queue if any message that it removes from the queue is always the i-th message removed from the queue during the execution of its worker. It is a compile time error if a receive action does not have an index in each of its queues.
A send action/statement and a receive action correspond if they have the same index in a queue.
It is a compile time error if two or more receive actions have the same index in a queue.
A send action/statement is in the same send set as another send action/statement if they have the same index in a queue. It is allowed for a send set to have more than one member.
The maximum index that a receive action has in a queue must be the same as the maximum index that a send action or statement has in that queue.
It is a compile time error if it is possible for a worker to terminate with success before it has executed all its receive actions.
It is a compile time error if it is possible for a worker to terminate with success before it has executed one member from every send set.

7.9 Remote interaction

A client object is a stub that allows a worker to send network messages to a remote process according to some protocol. A local variable declared with client object type will be depicted as a lifeline in the function's sequence diagram. The remote methods of the client object correspond to distinct network messages defined by the protocol for the role played by the client object. The return value of a remote method represents the protocol's response. A remote-method-call-action is depicted as a horizontal arrow from the worker lifeline to the client object lifeline.

remote-method-call-action := expression -> method-name ( arg-list )

Calls a remote method. This works the same as a method call expression, except that it is used only for a method with the remote modifier.

7.10 Local variable declaration statements

local-var-decl-stmt :=
   local-init-var-decl-stmt
   | local-no-init-var-decl-stmt
local-init-var-decl-stmt :=
   [annots] [final] typed-binding-pattern = action-or-expr ;

A local-var-decl-stmt is used to declare variables with a scope that is local to the block in which they occur.

The scope of variables declared in a local-var-decl-stmt starts immediately after the statement and continues to the end of the block statement in which it occurs.

A local-init-var-decl-stmt is executed by evaluating the action-or-expr resulting in a value, and then matching the typed-binding-pattern to the value, causing assignments to the variables occurring in the typed-binding-pattern. The typed-binding-pattern is used unconditionally, meaning that it is a compile error if the static types do not guarantee the success of the match. If the typed-binding-pattern uses var, then the type of the variable is inferred from the static type of the action-or-expr; if the local-init-var-decl-stmt includes final, the precise type is used, and otherwise the broad type is used. If the typed-binding-pattern specifies a type-descriptor, then that type-descriptor provides the contextually expected type for action-or-expr.

If final is specified, then the variables declared must not be assigned to outside the local-init-var-decl-stmt.

local-no-init-var-decl-stmt :=
   [annots] [final] type-descriptor variable-name ;

A local variable declared local-no-init-var-decl-stmt must be definitely assigned at each point that the variable is referenced. This means that the compiler must be able to verify that the local variable will have been assigned before that point. If final is specified, then the variable must not be assigned more than once.

7.11 Implicit variable type narrowing

Usually the type of a reference to a variable is determined by the variable's declaration, either explicitly specified by a type descriptor or inferred from the static type of the initializer.

In addition, this section defines cases where a variable is used in certain kinds of boolean expression in a conditional context, and it can be proved at compile time that the value stored in local variable or parameter will, within a particular region of code, always belong to a type that is narrower that the static type of the variable. In these cases, references to the variable within particular regions of code will have a static type that is narrower that the variable type.

Given an expression E with static type boolean, and a variable x with static type Tx, we define how to determine

a narrowed type for x implied by truth of E and
a narrowed type for x implied by falsity of E

based on the syntactic form of E as follows.

If E has the form x is T, then
- the narrowed type for x implied by truth of E is the intersection of Tx and T
- the narrowed type for x implied by falsity of E is Tx with T removed
If E has the form x == E1 or E1 == x where the static type of E1 is an expression whose static type is a singleton simple type T1, then
- the narrowed type for x implied by truth of E is the intersection of Tx and T1
- the narrowed type for x implied by falsity of E is Tx with T1 removed
If E has the form x != E1 or E1 != x where the static type of E1 is an expression whose static type is a singleton simple type T1, then
- the narrowed type for x implied by truth of E is Tx with T1 removed
- the narrowed type for x implied by falsity of E is the intersection of Tx and T1
If E has the form !E1, then
- the narrowed type for x implied by truth of E is the narrowed type for x implied by falsity of E1
- the narrowed type for x implied by falsity of E is the narrowed type for x implied by truth of E1
If E has the form E1 && E2
- the narrowed type for x implied by truth of E is the intersection of T1 and T2, where T1 is the narrowed type for x implied by the truth of T1 and T2 is the narrowed type for x implied by the truth of T2
- the narrowed type for x implied by falsity of E is T1|T2, where T1 is the narrowed type for x implied by the falsity of E1, and T2 is the intersection of T3 and T4, where T3 is the narrowed type for x implied by the truth of E1 and T4 is the narrowed type for x implied by the falsity of E2
If E has the form E1 || E2, then
- the narrowed type for x implied by truth of E is T1|T2, where T1 is the narrowed type for x implied by the truth of E1, and T2 is the intersection of T3 and T4, where T3 is the narrowed type for x implied by the falsity of E1 and T4 is the narrowed type for x implied by the truth of E2
- the narrowed type for x implied by falsity of E is the intersection of T1 and T2, where T1 is narrowed type for x implied by the falsity of E1 and T2 is the narrowed type for x implied by the falsity of E2
If E has any other form, then
- the narrowed type for x implied by the truth of E is Tx
- the narrowed type for x implied by the falsity of E is Tx

Narrowed types apply to regions of code as follows:

in an expression E1 || E2, the narrowed types implied by the falsity of E1 apply within E2
in an expression E1 && E2, the narrowed types implied by the truth of E1 apply within E2
in an expression E1 ? E2 : E3, the narrowed types implied by the truth of E1 apply within E2 and the narrowed types implied by the falsity of E1 apply within E3
in a statement if E1 { B1 } else { B2 }, the narrowed types implied by the truth of E1 apply within B1 and the narrowed types implied by the falsity of E1 apply within E2
in a match-clause P if E => { B }, the narrowed types implied by the truth of E apply within B
the narrowed type for a variable x no longer applies as soon as there is a possibility of x being assigned to

7.12 Local type definition statement

local-type-defn-stmt :=
   [annots] type identifier type-descriptor ;

A local-type-defn-stmt binds the identifier to a type descriptor within the scope of the current block. The type-descriptor is resolved when the statement is executed.

7.13 [Preview] XML namespace declaration statement

xmlns-decl-stmt := xmlns-decl
xmlns-decl := xmlns xml-namespace-uri [ as xml-namespace-prefix ] ;
xml-namespace-uri := simple-const-expr
xml-namespace-prefix := identifier

An xmlns-decl is used to declare a XML namespace. If there is an xml-namespace-prefix, then the in-scope namespaces that are used to perform namespace processing on an xml-expr will include a binding of that prefix to the specified xml-namespace-uri; otherwise the in-scope namespaces will include a default namespace with the specified xml-namespace-uri.

An xml-namespace-prefix declared by an xmlns-decl-stmt is in the same symbol space as a module-prefix declared by an import-decl. This symbol space is distinct from a module's main symbol space used by other declarations. An xmlns-decl in a xmlns-decl-stmt declares the prefix within the scope of the current block.

The static type of the simple-const-expr must be a subtype of string.

7.14 Assignment

There are three kinds of assignment statement:

an ordinary assignment statement, which is usually called simply an assignment statement,
a compound assignment statement, and
a destructuring assignment statement.

The first two of these build on the concept of an lvalue, whereas the last one builds on the concept of a binding pattern.

7.14.1 Lvalues

An lvalue is what the left hand side of an assignment evaluates to. An lvalue refers to a storage location which is one of the following:

a variable;
a specific named field of an object;
the member of a container having a specific key, which will be either an integer or a string according as the container is a list or a mapping.

An lvalue that is both defined and initialized refers to a storage location that holds a value:

an lvalue referring to a variable is always defined but may be uninitialized;
an lvalue referring to a specific named field of an object is always defined but may not be initialized until the __init method returns
an lvalue referring to member of a container having a specific key is undefined if the container does not have a member with that key; if such an lvalue is defined, it is also initialized; note that an lvalue always refers to a container that is already constructed.

lvexpr :=
   variable-reference-lvexpr
   | field-access-lvexpr
   | member-access-lvexpr

The left hand side of an assignment is syntactically a restricted type of expression, called an lvexpr. When the evaluation of an lvexpr completes normally, its result is an lvalue. The evaluation of an lvexpr can also complete abruptly, with a panic or check-fail, just as with the evaluation of an expression.

The compiler determines a static type for each lvexpr just as it does for expressions, but the meaning is slightly different. For an lvexpr L to have static type T means that if the runtime evaluation of L completes normally resulting in an lvalue x, then if x is defined and initialized, it refers to a storage location that holds a value belonging to type T. In addition to a type, the compiler determines for each lvexpr whether it is potentially undefined and whether it is potentially uninitialized.

An lvalue supports three operations: store, read and filling-read.

The fundamental operation on an lvalue is to store a value in the storage location it refers to. This operation does not required the lvalue to be defined or initialized; a successful store operation on an undefined lvalue will result in the addition of a member to the container; a store on an uninitialized lvalue will initialize it. When an lvalue refers to a variable, it is possible to determine at compile-time whether the store of a value is permissible based on the declaration of the variable and the static type of the value to be stored. However, when the lvalue refers to a member of a container, this is not in general possible for three reasons.

The guarantee provided by an lvalue having a static type T is not that the referenced storage location can hold every value that belongs to type T; rather the guarantee is that every value that the referenced storage location can hold belongs to type T. This is because of container types are covariant in their member types. The values that the storage location can actually hold are determined by the inherent type of the container.
The member may not be defined and the inherent type of the container may not allow a member with that specific key. The permissible keys of a container can be constrained by closed record types, fixed-length array types, and tuple types (with any rest descriptor).
The container may be immutable. The static type of an lvalue referring to a member of a container makes no guaranteees that the container is not immutable.

The first of these reasons also applies to lvalues that refer to fields of objects. Accordingly, stores to lvalues other than lvalues that refer to variables must be verified at runtime to ensure that they are not impermissible for any of the above three reasons. An attempt to perform an impermissible store results in a panic at runtime.

List values maintain the invariant that there is a unique integer n, the length of the list, such that a member k of the list is defined if and only if k is a non-negative integer less than n. When a store is performed on an lvalue referring to a member k of a list value and the length of the list is n and k is > n, then each member with index i for each <= i < k is filled in, by using the FillMember abstract operation. The FillMember abstract operation may fail; in particular it will fail if the list is a fixed-length array. If the FillMember operation fails, then the attempt to store will panic.

An lvalue also allows a read operation, which is used by the compound assignment statement. Unlike a store operation, a read operation cannot result in a runtime panic. A read operation cannot be performed on an lvalue that is undefined or uninitialized.

Finally, a lvalue supports a filling-read operation, which is used to support chained assignment. A filling-read is performed only an lvalue with a static type that is a container type. It differs from a read operation only when it is performed on a potentially undefined lvalue. If the lvalue is undefined at runtime, then the filling-read will use the FillMember abstract operation on the member that the lvalue refers to. If the FillMember operation fails, then the filling-read panics. Unlike the read operation, the filling-read operation can be performed on an undefined lvalue; it cannot, however, be performed on an uninitialized lvalue.

The evaluation of an lvexpr is specified in terms of the evaluation of its subexpressions, the evaluation of its sub-lvexprs, and store and filling-read operations on lvalues. If any of these result in a panic, then the evaluation of the lvexpr completes abruptly with a panic.

variable-reference-lvexpr := variable-reference

The result of evaluating variable-reference-lvexpr is an lvalue referring to a variable. Its static type is the declared or inferred type of the variable. The lvexpr is potentially uninitialized if it is possible for execution to have reached this point without initializing the referenced variable.

field-access-lvexpr := lvexpr . field-name

The static type of lvexpr must be either a subtype of the mapping basic type or a subtype of the object basic type.

In the case where the static type of lvexpr is a subtype of the object basic type, the object type must have a field with the specified name, and the resulting lvalue refers to that object field.

In the case where the static type of lvexpr is a subtype of the mapping basic type, the semantics are as follows.

The following requirements apply at compile time: the type of lvexpr must include mapping shapes that have the specified field-name; type descriptor for lvexpr must include field-name as an individual-type-descriptor (if lvexpr is a union, then this requirement applies to every member of the union); lvexpr must not be potentially uninitialized, but may be potentially undefined.
It is evaluated as follows:
1. evaluate lvexpr to get lvalue lv;
2. perform a filling-read operation on lv to get mapping value m;
3. the result is an lvalue referring to the member of m with the specified field-name.
The static type of the field-access-expr is the member type for the key type K in T, where T is the static type of the lvexpr and K is the singleton string type containing the field-name; the field-access-expr is potentially undefined if K is an optional key type for T.

member-access-lvexpr := lvexpr [ expression ]

The static type of lvexpr must be either a subtype of the mapping basic type or a subtype of the list basic type. In the former case, the contextually expected type of expression must be string and it is an error if the static type of expression is not string; in the latter case, the contextually expected type of expression must be int and it is an error if the static type of expression is not int.

It is evaluated as follows:

evaluate expression to get a string or int k;
evaluate lvexpr to get lvalue lv;
perform a filling-read operation on lv to get a list or mapping value v;
the result is an lvalue referring to the member of c with key k.

The static type of the member-access-expr is the member type for the key type K in T, where T is the static type of the lvexpr and K is the static type type of expression; the member-access-expr is potentially undefined if K is an optional key type for T.

7.14.2 Assignment statement

assignment-stmt := lvexpr = action-or-expr ;

The static type of action-or-expr must be a subtype of the static type of lvexpr. The static type of lvexpr provides the contextually expected type for action-or-expr. It is not an error for lvexpr to be potentially undefined or potentially uninitialized.

It is executed at as follows:

execute action-or-expr to get a value v;
evaluate lvexpr to get an lvalue lv;
perform the store operation of lv with value v.

7.14.3 Compound assignment statement

compound-assignment-stmt := lvexpr CompoundAssignmentOperator action-or-expr ;
CompoundAssignmentOperator := BinaryOperator =
BinaryOperator := + | - | * | / | & | | | ^ | << | >> | >>>

It is a compile error if lvexpr is potentially undefined unless the static type of lvexpr is a subtype of the list basic type. It is a compile error if lvexpr is potentially uninitialized.

Let T1 be the static type of lvexpr, and let T2 be the static type of action-expr. Then let T3 be the static type of an expression E1 BinaryOp E2 where E1 has type T1 and E2 has type T2. It is a compile error if T3 is not a subtype of T1.

It is executed as follows:

execute action-or-expr to get a value v2;
evaluate lvexpr to get an lvalue lv;
if lv is undefined, panic (lv must refer to an undefined member of a list)
perform the read operation on lv to get a value v1
perform the operation specified by BinaryOperator on operands v1 and v2, resulting in a value v3
perform the store operation on lv with value v3.

7.14.4 Destructuring assignment statement

destructuring-assignment-stmt :=
   binding-pattern-not-variable-reference = action-or-expr ;
binding-pattern-not-variable-reference :=
   wildcard-binding-pattern
   | list-binding-pattern
   | mapping-binding-pattern
   | error-binding-pattern

A destructuring assignment is executed by evaluating the action-or-expr resulting in a value v, and then matching the binding pattern to v, causing assignments to the variables occurring in the binding pattern.

The binding-pattern has a static type implied by the static type of the variables occurring in it. The static type of action-or-expr must be a subtype of this type.

7.15 Action statement

action-stmt := action ;

An action-stmt is a statement that is executed by evaluating an action and discarding the resulting value, which must be nil. It is a compile-time error if the static type of an action in an action-stmt is not nil.

7.16 Call statement

call-stmt := call-expr ;
call-expr :=
   function-call-expr
   | method-call-expr
   | checking-keyword call-expr
   | trap call-expr

A call-stmt is executed by evaluating call-expr as an expression and discarding the resulting value, which must be nil. It is a compile-time error if the static type of the call-expr in an call-stmt is not nil.

7.17 Conditional statement

if-else-stmt :=
   if expression block-stmt 
   [ else if expression block-stmt ]* 
   [ else block-stmt ]

The if-else statement is used for conditional execution.

The static type of the expression following if must be boolean. When an expression is true then the corresponding block statement is executed and the if statement completes. If no expression is true then, if the else block is present, the corresponding block statement is executed.

7.18 Match statement

match-stmt := match action-or-expr { match-clause+ }
match-clause :=
  match-pattern-list [match-guard] => block-stmt
match-guard := if expression

A match statement selects a block statement to execute based on which patterns a value matches.

A match-stmt is executed as follows:

the expression is evaluated resulting in some value v;
for each match-clause in order:
1. a match of match-pattern against v is attempted
2. if the attempted match fails, the execution of the match-stmt continues to the next match-clause
3. if the attempted match succeeds, then the variables in match-pattern are created
4. if there is a match-guard, then the expression in match-guard is executed resulting in a value b
5. if b is false, then the execution of the match-stmt continues to the next match-clause
6. otherwise, the block-stmt in the match-clause is executed
7. execution of the match-stmt completes

The scope of any variables created in a match-pattern-list of a match-clause is both the match-guard, if any, and the block-stmt in that match-clause. The static type of the expression in match-guard must be a subtype of boolean.

match-pattern-list := 
  match-pattern (| match-pattern)*

A match-pattern-list can be matched against a value. An attempted match can succeed or fail. A match-pattern-list is matched against a value by attempting to match each match-pattern until a match succeeds.

All the match-patterns in a given match-pattern-list must bind the same set of variables.

match-pattern :=
  var binding-pattern
   | wildcard-match-pattern
   | const-pattern
   | list-match-pattern
   | mapping-match-pattern
   | error-match-pattern

A match-pattern combines the destructuring done by a binding-pattern with the ability to match a constant value.

Note that an identifier can be interpreted in two different ways within a match-pattern:

in the scope of a var, an identifier names a variable which is to be bound to a part of the matched value when a pattern match succeeds;
outside the scope of a var, an identifier references a constant that a value must match for the pattern match to succeed.

A match-pattern must be linear: a variable that is to be bound cannot occur more than once in a match-pattern.

const-pattern := simple-const-expr

A const-pattern denotes a single value. Matching a const-pattern against a value succeeds if the value has the same shape as the value denoted by the const-pattern. A variable-reference in a const-pattern must refer to a constant. Successfully matching a const-pattern does not cause any variables to be created.

Matching a wildcard-match-pattern against a value succeeds if the value belongs to type any, in other words if the basic type of the value is not error.

wildcard-match-pattern := _
list-match-pattern := [ list-member-match-patterns ]
list-member-match-patterns :=
   match-pattern (, match-pattern)* [, rest-match-pattern]
   | [ rest-match-pattern ]
mapping-match-pattern := { field-match-patterns }
field-match-patterns :=
   field-match-pattern (, field-match-pattern)* [, rest-match-pattern]
   | [ rest-match-pattern ] 
field-match-pattern := field-name : match-pattern
rest-match-pattern := ... var variable-name
error-match-pattern := direct-error-match-pattern | indirect-error-match-pattern
direct-error-match-pattern := error ( direct-error-arg-list-match-pattern )
indirect-error-match-pattern := error-type-reference ( indirect-error-arg-list-match-pattern )
direct-error-arg-list-match-pattern :=
   simple-match-pattern [, error-field-match-patterns]
   | [error-field-match-patterns]
indirect-error-arg-list-match-pattern := [error-field-match-patterns]
error-field-match-patterns :=
   named-arg-match-pattern (, named-arg-match-pattern)* [, rest-match-pattern]
   | rest-match-pattern
simple-match-pattern :=
   wildcard-match-pattern
   | const-pattern
   | var variable-name
named-arg-match-pattern := arg-name = match-pattern

Matching a mapping-match-pattern against a mapping value succeeds if and only every field-match-pattern matches against a field of the value. The variable in the rest-match-pattern, if specified, is bound to a new mapping that contains just the fields for which that did not match a field-match-pattern.

For a match of an indirect-error-match-pattern against an error value to succeed, the error type referenced by the error-type-reference must contain the shape of the error value; since errors are immutable, this requirement is equivalent to requiring that the error value belong to the referenced error type.

7.19 Foreach statement

foreach-stmt :=
   foreach typed-binding-pattern in action-or-expr block-stmt

A foreach statement iterates over a sequence, executing a block statement once for each member of the sequence.

The scope of any variables created in typed-binding-pattern is block-stmt. These variables are implicitly final.

In more detail, a foreach statement executes as follows:

evaluate the expression resulting in a value c
create an iterator object i from c as follows
1. if c is a basic type that is iterable, then i is the result of calling c.iterator()
2. if c is an object and c belongs to Iterable<T> for some T, then i is the result of calling c.__iterator()
call i.next() resulting in a value n
if n is nil, then terminate execution of the foreach statement
match typed-binding-pattern to n.value causing assignments to any variables that were created in typed-binding-pattern
execute block-stmt with the variable bindings from step 5 in scope; in the course of so doing
1. the execution of a break-stmt terminates execution of the foreach statement
2. the execution of a continue-stmt causes execution to proceed immediately to step 3
go back to step 3

In step 2, the compiler will give an error if the static type of expression is not suitable for 2a or 2b.

In step 5, the typed-binding-pattern is used unconditionally, and the compiler will check that the static types guarantee that the match will succeed. If the typed-binding-pattern uses var, then the type will be inferred from the type of expression.

7.20 While statement

while-stmt := while expression block-stmt

A while statement repeatedly executes a block statement so long as a boolean-valued expression evaluates to true.

In more detail, a while statement executes as follows:

evaluate expression;
if expression evaluates to false, terminate execution of the while statement;
execute block-stmt; in the course of so doing
1. the execution of a break-stmt results in termination of execution of the while statement
2. the execution of a continue-stmt causes execution to proceed immediately to step 1
go back to step 1.

The static type of expression must be a subtype of boolean.

7.21 Continue statement

continue-stmt := continue ;

A continue statement is only allowed if it is lexically enclosed within a while-stmt or a foreach-stmt. Executing a continue statement causes execution of the nearest enclosing while-stmt or foreach-stmt to jump to the end of the outermost block-stmt in the while-stmt or foreach-stmt.

7.22 Break statement

break-stmt := break ;

A break statement is only allowed if it is lexically enclosed within a while-stmt or a foreach-stmt. Executing a break statement causes the nearest enclosing while-stmt or foreach-stmt to terminate.

7.23 Panic statement

panic-stmt := panic expression ;

A panic statement terminates the current worker abnormally. The result of evaluating expression provides the termination value of the worker.

The static type of expression must be a subtype of error.

7.24 Return statement

return-stmt := return [ action-or-expr ] ;

A return statement terminates the current worker normally.The result of evaluating the action-or-expr provides the termination value of the worker. If action-or-expr is omitted, then the termination value is nil.

8. Module-level declarations

Each source part in a Ballerina module must match the production module-part.

The import declarations must come before other declarations; apart from this, the order of the definitions and declarations at the top-level of a module is not constrained.

module-part := import-decl* other-decl*
other-decl :=
   listener-decl
   | service-decl
   | function-defn
   | module-type-defn
   | module-const-decl
   | module-var-decl
   | module-xmlns-decl
   | annotation-decl

8.1 Import declaration

import-decl := 
   import [org-name /] module-name [version sem-ver] 
   [as import-prefix] ;
import-prefix := module-prefix | _
module-prefix := identifier
org-name := identifier
module-name := identifier (. identifier)*
sem-ver := major-num [. minor-num [. patch-num]]
major-num := DecimalNumber
minor-num := DecimalNumber
patch-num := DecimalNumber

qualified-identifier := module-prefix : identifier

A module-prefix is a name that is used locally within the source of a module to refer to another module. A module-prefix in a qualified-identifier must refer to a module-prefix specified in an import-declaration in the same source part.

An import-prefix of _ causes the module to be imported without making its symbols available via a module-prefix. In this case, the effect of importing the module will be just to cause the module to be included in the program and initialized. It is an error for a source-part to import a module using a module-prefix and then not to use that module-prefix.

A module-prefix declared by an import-decl is in the same symbol space as a xmlns-namespace-prefix declared by an xmlns-decl-stmt. This symbol space is distinct from a module's main symbol space used by other declarations.

It is an error for a module to directly or indirectly import itself. In other words, the directed graph of module imports must be acyclic.

8.2 Module and program execution

A Ballerina program consists of one or more modules; one of these modules is distinguished as the root module. The source code for a module uses import declarations to identify the modules on which it depends directly. At compile-time, a root module is specified, and the modules comprising the program are inferred to be those that the root module imports directly or indirectly. The directed graph of module imports must be acyclic.

Program execution may terminate successfully or unsuccessfully. Unsuccessful program termination returns an error value. Program execution consists of two consecutive phases: an initialization phase and a listening phase.

Module initialization is performed by calling an initialization function, which is synthesized by the compiler for each module. Module initialization can fail, in which case the initialization function returns an error value. The initialization phase of program execution consists of initializing each of the program's modules. If the initialization of a module is unsuccessful, then program execution immediately terminates unsuccessfully, returning the error value returned by the initialization function.

The initialization of a program's modules is ordered so that a module will not be initialized until all of the modules on which it depends have been initialized. (Such an ordering will always be possible, since the graph of module imports is required to be acyclic.) The order in which modules are initialized follows the order in which modules are imported so far as is consistent with the previous constraint.

A module's initialization function performs expression evaluation so as to initialize the identifiers declared in the module's declarations; if evaluation of an expression completes abruptly, then the module initialization function immediately returns the error value associated with the abrupt completion. If a module defines a function named __init, then a module's initialization function will end by calling this function; if it terminates abruptly or returns an error, then the module's initialization function will return an error value. Note that the __init function of the root module will be the last function called during a program's initialization phase.

This specification does not define any mechanism for processing the program command-line arguments typically provided by an operating system. The Ballerina standard library provides a function to retrieve these command-line arguments. In addition, the Ballerina platform provides a convenient mechanism for processing these arguments. This works by generating a new command-line processing module from the specified root module. The __init function of the generated module retrieves the command-line arguments, parses them, and calls a public function of the specified root module (typically the main function). The parsing of the command-line arguments is controlled by the declared parameter types, annotations and names of the public functions. The generated module, which imports the specified root module, becomes the new root module.

If the initialization phase of program execution completes successfully, then execution proceeds to the listening phase, which is described in the next section. The termination of the listening phase, which may be successful or unsuccessful, terminates the program execution.

8.3 Listeners and services

Services have resource methods, which are the network entry points of a Ballerina program. Listeners provide the interface between the network and services. A listener object receives network messages from a remote process according to some protocol and translates the received messages into calls on the resource methods of service values that have been attached to the listener object. It is up to the listener object to determine how this translation happens; the type of the listener object thus constrains the type of a service that can be attached to the listener. (This constraint is not yet enforced by Ballerina's type system.)

The return type of a resource method represents whether the method successfully handled the protocol message. The listener typically calls a resource method with a client object as a parameter. The remote methods on the client object correspond to the distinct network messages defined by the protocol as possible responses to the message that the resource method is handling. A resource method called by a listener as a result of a network message received from a remote process can then use the client object to send a response message back to that remote process.

The methods defined by the Listener abstract object type allow for the management of the lifecycle of a listener object and its attached services. A listener declaration registers a listener object with a module, so that it can be managed by the module. The runtime state of each module includes a list of listener objects that have been registered with the module. A listener object that has been registered with a module is called a module listener

If at the start of the listening phase of program execution there are no module listeners, then the listening phase immediately terminates successfully. Otherwise, the __start method of each module listener is called; if any of these calls returns an error value, then the listening phase terminates unsuccessfully with this error value as its return value.

The listening phase of program execution continues until either the program explicitly exits, by calling a standard library function, or the user explicitly requests the termination of the program using an implementation-dependent operating system facility (such as a signal on a POSIX system). In the latter case, the __gracefulStop or __immediateStop method of each registered listener will be called before termination.

8.3.1 Listener declaration

listener-decl :=
   metadata
   [public] listener [type-descriptor] variable-name = expression ;

A listener-decl declares a module listener. A module listener declares a variable in a similar way to a final variable declaration, but the type of the variable is always a subtype of the Listener abstract object type, and it has the additional semantic of registering the variable's value with the module as a listener. As with a variable declared in a final variable declaration, the variable can be referenced by a variable-reference, but cannot be assigned to. A module may have multiple multiple listeners.

If the type-descriptor is present it specifies the static type of the variable; if it is not present, the the static type is the static type of expression. In both cases, the static type is constrained to be a subtype of the Listener abstract object type.

When a listener-decl is initialized as part of module initialization, its expression is evaluated. If expression evaluation completes abruptly, then module initialization fails. Otherwise the variable is initialized with the result of the evaluation.

8.3.2 Service declaration

service-decl :=
  metadata
  service [variable-name] on expression-list service-body-block
expression-list := expression (, expression)*

A service-decl creates a service and attaches it to one or more listeners. If a variable-name is specified, it also declares a variable; as with a variable declared in a final variable declaration, the variable can be referenced by a variable-reference, but cannot be assigned to.

The service-body-block has the same semantics as in a service-constructor-expr. The static type of each expression in the expression list must be a subtype of the union of error with the Listener abstract object type. If an implementation is using annotations to provide more precise typing of services, then any annotations on the service type that is the first parameter of the __attach method in the object type of each expression in expression list will constrain the type of the service value constructed by the service-body-block.

A service-decl is initialized as part of module initialization as follows. The service-body-block is evaluated as in a service-constructor resulting in a service value s. If variable-name is specified, then the variable is initialized to s. Then for each expression in expression-list:

the expression is evaluated resulting in a value which is either an error or an object obj that is a subtype of Listener;
if it is an error, module initialization fails;
otherwise, obj is registered as a module listener (registering the same object multiple times is the same as registering it once);
s is then attached to obj using obj's __attach method;
if the call to __attach fails, then module initialization fails.

8.4 Function definition

function-defn := 
   metadata
   [public]
   function identifier function-signature function-body
function-body := function-body-block | external-function-body
external-function-body := = [annots] external ;

An external-function-body means that the implementation of the function is not provided in the Ballerina source module.

If a module has a function-defn with an identifier of __init, it is called called automatically by the system at the end of the initialization of that module; if this call returns an error, then initialization of the module fails. The following special requirements apply to the __init function of a module: it must not be declared public; its return type must both be a subtype of error? and contain (); it must have no parameters.

8.5 Module type definition

module-type-defn :=
   metadata
   [public] type identifier type-descriptor ;

8.6 Module variable declaration

module-var-decl :=
   metadata
   [final]
   typed-binding-pattern = expression ;

The scope of variables declared in a module-var-decl is the entire module. Note that module variables are not allowed to be public. If final is specified, then it is not allowed to assign to the variable. If the typed-binding-pattern uses var, then the type of the variable is inferred from the static type of expression; if the module-var-decl includes final, the precise type is used, and otherwise the broad type is used. If the typed-binding-pattern specifies a type-descriptor, then that type-descriptor provides the contextually expected type for action-or-expr.

8.7 Module constant declaration

module-const-decl :=
   metadata
   [public] const [type-descriptor] identifier = const-expr ;

A module-const-decl declares a compile-time constant. A compile-time constant is an named immutable value, known at compile-time. A compile-time constant can be used like a variable, and can also be referenced in contexts that require a value that is known at compile-time, such as in a type-descriptor or in a match-pattern.

The type of the constant is the singleton type containing just the shape of the value named by the constant. The type of the constant determines the static type of a variable-reference-expr that references this constant.

If type-descriptor is present, then it provides the contextually expected type for the interpretation of const-expr. It is a compile-time error if the static type of const-expr is not a subtype of that type. The type-descriptor must specify a type that is a subtype of anydata. Note that the type-descriptor does not specify the type of the constant, although the type of the constant will all be a subtype of the type specified by the type-descriptor.

8.8 [Preview] Module XML namespace declaration

module-xmlns-decl := xmlns-decl

A module-xmlns-decl declares an XML namespace prefix with module scope.

Attachment point name	Syntactic attachment point(s)	Attached to which type descriptor at runtime
type	module-type-defn, local-type-defn-stmt, type-cast-expr	defined type
object type	module-type-defn or local-type-defn-stmt, whose type descriptor is a non-abstract object type descriptor	defined type (which will be type of objects constructed using this type)
function	function-defn, method-decl, method-defn, anonymous-function-expr, service-method-defn	type of function
resource function	service-method-defn with resource modifier	type of function, on service value
return	returns-type-descriptor	indirectly to type of function
parameter	individual-param, rest-param	indirectly to type of function
service	service-decl, service-constructor-expr	type of service
listener	listener-decl	none
var	module-var-decl, local-var-decl-stmt	none
const	module-const-decl	none
annotation	annotation-decl	none
external	external-function-body	none
worker	named-worker-decl, start-action	none