OLD | NEW |
---|---|
1 \documentclass{article} | 1 \documentclass{article} |
2 \usepackage{epsfig} | 2 \usepackage{epsfig} |
3 \usepackage{dart} | 3 \usepackage{dart} |
4 \usepackage{bnf} | 4 \usepackage{bnf} |
5 \usepackage{hyperref} | 5 \usepackage{hyperref} |
6 \newcommand{\code}[1]{{\sf #1}} | 6 \newcommand{\code}[1]{{\sf #1}} |
7 \title{Dart Programming Language Specification \\ | 7 \title{Dart Programming Language Specification \\ |
8 {\large Version 1.6}} | 8 {\large Version 1.6}} |
9 %\author{The Dart Team} | 9 %\author{The Dart Team} |
10 \begin{document} | 10 \begin{document} |
(...skipping 234 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
245 } | 245 } |
246 | 246 |
247 \rationale{Privacy is, at this point, a static notion tied to a particular piece of code (a library). It is designed to support software engineering concerns ra ther than security concerns. Untrusted code should always run in an another isol ate. It is possible that libraries will become first class objects and privacy will be a dynamic notion tied to a library instance. | 247 \rationale{Privacy is, at this point, a static notion tied to a particular piece of code (a library). It is designed to support software engineering concerns ra ther than security concerns. Untrusted code should always run in an another isol ate. It is possible that libraries will become first class objects and privacy will be a dynamic notion tied to a library instance. |
248 | 248 |
249 Privacy is indicated by the name of a declaration - hence privacy and naming are not orthogonal. This has the advantage that both humans and machines can recogn ize access to private declarations at the point of use without knowledge of the context from which the declaration is derived.} | 249 Privacy is indicated by the name of a declaration - hence privacy and naming are not orthogonal. This has the advantage that both humans and machines can recogn ize access to private declarations at the point of use without knowledge of the context from which the declaration is derived.} |
250 | 250 |
251 \subsection{Concurrency} | 251 \subsection{Concurrency} |
252 | 252 |
253 Dart code is always single threaded. There is no shared-state concurrency in Dar t. Concurrency is supported via actor-like entities called {\em isolates}. | 253 Dart code is always single threaded. There is no shared-state concurrency in Dar t. Concurrency is supported via actor-like entities called {\em isolates}. |
254 | 254 |
255 An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (\ref{sendingMessages}). No st ate is ever shared between isolates. Isolates are created by spawning (\ref{spaw ningAnIsolate}). | 255 An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (\ref{sendingMessages}). No st ate is ever shared between isolates. Isolates are created by spawning (\ref{spaw ningAnIsolate}). |
256 | 256 |
257 | 257 |
258 \section{Errors and Warnings} | 258 \section{Errors and Warnings} |
259 \label{errorsAndWarnings} | 259 \label{errorsAndWarnings} |
260 | 260 |
261 This specification distinguishes between several kinds of errors. | 261 This specification distinguishes between several kinds of errors. |
262 | 262 |
263 {\em Compile-time errors} are errors that preclude execution. A compile-time err or must be reported by a Dart compiler before the erroneous code is executed. | 263 {\em Compile-time errors} are errors that preclude execution. A compile-time err or must be reported by a Dart compiler before the erroneous code is executed. |
264 | 264 |
265 \rationale{A Dart implementation has considerable freedom as to when compilation takes place. Modern programming language implementations often interleave compi lation and execution, so that compilation of a method may be delayed, e.g., unt il it is first invoked. Consequently, compile-time errors in a method $m$ may be reported as late as the time of $m$'s first invocation. | 265 \rationale{A Dart implementation has considerable freedom as to when compilation takes place. Modern programming language implementations often interleave compi lation and execution, so that compilation of a method may be delayed, e.g., unt il it is first invoked. Consequently, compile-time errors in a method $m$ may be reported as late as the time of $m$'s first invocation. |
(...skipping 208 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
474 \begin{grammar} | 474 \begin{grammar} |
475 {\bf functionSignature:} | 475 {\bf functionSignature:} |
476 metadata returnType? identifier formalParameterList | 476 metadata returnType? identifier formalParameterList |
477 . | 477 . |
478 | 478 |
479 {\bf returnType:} | 479 {\bf returnType:} |
480 \VOID{}; | 480 \VOID{}; |
481 type | 481 type |
482 . | 482 . |
483 | 483 |
484 {\bf functionBody:}`={\escapegrammar \gt}' expression `{\escapegrammar ;}'; | 484 {\bf functionBody:} \ASYNC{}? `={\escapegrammar \gt}' expression `{\escapegramm ar ;}'; |
485 block | 485 (\ASYNC{} $|$ \ASYNC* $|$ \SYNC*)? block |
486 . | 486 . |
487 | 487 |
488 {\bf block:} | 488 {\bf block:} |
489 `\{' statements `\}' | 489 `\{' statements `\}' |
490 . | 490 . |
491 | 491 |
492 \end{grammar} | 492 \end{grammar} |
493 | 493 |
494 Functions include function declarations (\ref{functionDeclarations}), methods ( \ref{instanceMethods}, \ref{staticMethods}), getters (\ref{getters}), setters (\ref{setters}), constructors (\ref{constructors}) and function literals (\re f{functionExpressions}). | 494 Functions include function declarations (\ref{functionDeclarations}), methods ( \ref{instanceMethods}, \ref{staticMethods}), getters (\ref{getters}), setters (\ref{setters}), constructors (\ref{constructors}) and function literals (\re f{functionExpressions}). |
495 | 495 |
496 All functions have a signature and a body. The signature describes the formal pa rameters of the function, and possibly its name and return type. A function bod y is either: | 496 All functions have a signature and a body. The signature describes the formal pa rameters of the function, and possibly its name and return type. A function bod y is either: |
497 \begin{itemize} | 497 \begin{itemize} |
498 \item A block statement (\ref{blocks}) containing the statements (\ref{stateme nts}) executed by the function. In this case, if the last statement of a functio n is not a return statement, the statement \code{\RETURN{};} is implicitly appen ded to the function body. | 498 \item A block statement (\ref{blocks}) containing the statements (\ref{stateme nts}) executed by the function, optionally marked with one of the modifiers: \AS YNC, \ASYNC* or \SYNC*. In this case, if the last statement of a function is not a return statement (\ref{return}), the statement \code{\RETURN{};} is implicitl y appended to the function body. |
499 | 499 |
500 \rationale{ | 500 \rationale{ |
501 Because Dart is optionally typed, we cannot guarantee that a function that does not return a value will not be used in the context of an expression. Therefore, every function must return a value. A \RETURN{} without an expression returns \N ULL{}. See further discussion in section \ref{return}. | 501 Because Dart is optionally typed, we cannot guarantee that a function that does not return a value will not be used in the context of an expression. Therefore, every function must return a value. A \RETURN{} without an expression returns \N ULL{}. For generator functions, the situation is more subtle. See further discus sion in section \ref{return}. |
502 } | 502 } |
503 | 503 |
504 OR | 504 OR |
505 \item of the form \code{=$>$ $e$} which is equivalent to a body of the form \c ode{\{\RETURN{} $e$;\}}. | 505 \item of the form \code{=$>$ $e$} which is equivalent to a body of the form \c ode{\{\RETURN{} $e$;\}} or the form \code{\ASYNC{} =$>$ $e$} which is equivalent to a body of the form \code{\ASYNC{} \{\RETURN{} $e$;\}}. \rationale{The other modifiers do not apply here, because they apply only to generators, discussed be low, and generators do not allow the form \code{\RETURN{} $e$}; values are added to the generated stream or iterable using \YIELD{} instead.} |
506 | |
506 \end{itemize} | 507 \end{itemize} |
507 | 508 |
509 A function is {\em asynchronous} if its body is marked with the \ASYNC{} or \ASY NC* modifier. Otherwise the function is {\em synchronous}. A function is a {\em generator} if its body is marked with the \SYNC* or \ASYNC* modifier. | |
508 | 510 |
511 \commentary{ | |
512 Whether a function is synchronous or asynchronous is orthogonal to whether it is a generator or not. Generator functions are a sugar for functions that produce collections in a systematic way, by lazily applying a function that {\em generat es} individual elements of a collection. Dart provides such a sugar in both the synchronous case, where one returns an iterable, and in the asynchronous case, w here one returns a stream. Dart also allows both synchronous and asynchronous fu nctions that produce a single value. | |
513 } | |
509 | 514 |
510 % A function has a formal parameter scope and a body scope. The enclosing scope of a function's body scope is its formal parameter scope. The enclosing scope o f the formal parameter scope of a function is the enclosing scope of the functi on. | 515 It is a compile-time error if an \ASYNC, \ASYNC* or \SYNC* modifier is attached to the body of a setter or constructor. |
511 | 516 |
512 % The body of a function $f$ is processed within the body scope of $f$. | 517 \rationale{ |
513 %\rationale{This may seem obvious, but needs to be stated.} | 518 An asynchronous setter would be of little use, since setters can only be used in the context of an assignment (\ref{assignment}), and an assignment expression a lways evaluates to the value of the assignment's right hand side. If the setter actually did its work asynchronously, one might imagine that one would return a future that resolved to the assignment's right hand side after the setter did it s work. However, this would require dynamic tests at every assignment, and so wo uld be prohibitively expensive. |
514 % \commentary{It follows from the above rules that the formal parameters of a fu nction may be referenced within its body. } | 519 |
520 An asynchronous constructor would, by definition, never return an instance of th e class it purports to construct, but instead return a future. Calling such a be ast via \NEW{} would be very confusing. If you need to produce an object asynchr onously, use a method. | |
521 | |
522 One could allow modifiers for factories. A factory for \code{Future} could be mo dified by \ASYNC{}, a factory for \code{Stream} could be modified by \ASYNC* and a factory for \code{Iterable} could be modified by \SYNC*. No other scenario ma kes sense because the object returned by the factory would be of the wrong type. This situation is very unusual so it is not worth making an exception to the ge neral rule for constructors in order to allow it. | |
523 } | |
524 | |
515 | 525 |
516 \subsection{Function Declarations} | 526 \subsection{Function Declarations} |
517 \label{functionDeclarations} | 527 \label{functionDeclarations} |
518 | 528 |
519 A {\em function declaration} is a function that is neither a member of a class n or a function literal. Function declarations include {\em library functions}, wh ich are function declarations | 529 A {\em function declaration} is a function that is neither a member of a class n or a function literal. Function declarations include {\em library functions}, wh ich are function declarations |
520 %(including getters and setters) | 530 %(including getters and setters) |
521 at the top level of a library, and {\em local functions}, which are function dec larations declared inside other functions. Library functions are often referred to simply as top-level functions. | 531 at the top level of a library, and {\em local functions}, which are function dec larations declared inside other functions. Library functions are often referred to simply as top-level functions. |
522 | 532 |
523 A function declaration consists of an identifier indicating the function's name, possibly prefaced by a return type. The function name is followed by a signatur e and body. For getters, the signature is empty. The body is empty for function s that are external. | 533 A function declaration consists of an identifier indicating the function's name, possibly prefaced by a return type. The function name is followed by a signatur e and body. For getters, the signature is empty. The body is empty for function s that are external. |
524 | 534 |
(...skipping 20 matching lines...) Expand all Loading... | |
545 It is a compile-time error to preface a function declaration with the built-in i dentifier \STATIC{}. | 555 It is a compile-time error to preface a function declaration with the built-in i dentifier \STATIC{}. |
546 | 556 |
547 When we say that a function $f_1$ {\em forwards} to another function $f_2$, we m ean that invoking $f_1$ causes $f_2$ to be executed with the same arguments an d/or receiver as $f_1$, and returns the result of executing $f_2$ to the caller of $f_1$, unless $f_2$ throws an exception, in which case $f_1$ throws the same exception. Furthermore, we only use the term for synthetic functions introduced by the specification. | 557 When we say that a function $f_1$ {\em forwards} to another function $f_2$, we m ean that invoking $f_1$ causes $f_2$ to be executed with the same arguments an d/or receiver as $f_1$, and returns the result of executing $f_2$ to the caller of $f_1$, unless $f_2$ throws an exception, in which case $f_1$ throws the same exception. Furthermore, we only use the term for synthetic functions introduced by the specification. |
548 | 558 |
549 | 559 |
550 \subsection{Formal Parameters} | 560 \subsection{Formal Parameters} |
551 \label{formalParameters} | 561 \label{formalParameters} |
552 | 562 |
553 Every function includes a {\em formal parameter list}, which consists of a list of required positional parameters (\ref{requiredFormals}), followed by any optio nal parameters (\ref{optionalFormals}). The optional parameters may be specified either as a set of named parameters or as a list of positional parameters, but not both. | 563 Every function includes a {\em formal parameter list}, which consists of a list of required positional parameters (\ref{requiredFormals}), followed by any optio nal parameters (\ref{optionalFormals}). The optional parameters may be specified either as a set of named parameters or as a list of positional parameters, but not both. |
554 | 564 |
555 The formal parameter list of a function introduces a new scope known as the func tion`s {\em formal parameter scope}. The formal parameter scope of a function $f $ is enclosed in the scope where $f$ is declared. Every formal parameter intr oduces a local variable into the formal parameter scope. However, the scope of a function's signature is the function's enclosing scope, not the formal paramete r scope. | 565 The formal parameter list of a function introduces a new scope known as the func tion's {\em formal parameter scope}. The formal parameter scope of a function $f $ is enclosed in the scope where $f$ is declared. Every formal parameter intr oduces a local variable into the formal parameter scope. However, the scope of a function's signature is the function's enclosing scope, not the formal paramete r scope. |
556 | 566 |
557 The body of a function introduces a new scope known as the function`s {\em body scope}. The body scope of a function $f$ is enclosed in the scope introduced by the formal parameter scope of $f$. | 567 The body of a function introduces a new scope known as the function's {\em body scope}. The body scope of a function $f$ is enclosed in the scope introduced by the formal parameter scope of $f$. |
558 | 568 |
559 | 569 |
560 %The formal parameter scope of a function maps the name of each formal parameter $p$ to the value $p$ is bound to. | 570 %The formal parameter scope of a function maps the name of each formal parameter $p$ to the value $p$ is bound to. |
561 | 571 |
562 % The formal parameters of a function are processed in the enclosing scope of th e function. | 572 % The formal parameters of a function are processed in the enclosing scope of th e function. |
563 % \commentary{this means that the parameters themselves may not be referenced wi thin the formal parameter list.} | 573 % \commentary{this means that the parameters themselves may not be referenced wi thin the formal parameter list.} |
564 | 574 |
565 It is a compile-time error if a formal parameter is declared as a constant varia ble (\ref{variables}). | 575 It is a compile-time error if a formal parameter is declared as a constant varia ble (\ref{variables}). |
566 | 576 |
567 \begin{grammar} | 577 \begin{grammar} |
(...skipping 247 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
815 \label{instanceMethods} | 825 \label{instanceMethods} |
816 | 826 |
817 Instance methods are functions (\ref{functions}) whose declarations are immediat ely contained within a class declaration and that are not declared \STATIC{}. Th e instance methods of a class $C$ are those instance methods declared by $C$ and the instance methods inherited by $C$ from its superclass. | 827 Instance methods are functions (\ref{functions}) whose declarations are immediat ely contained within a class declaration and that are not declared \STATIC{}. Th e instance methods of a class $C$ are those instance methods declared by $C$ and the instance methods inherited by $C$ from its superclass. |
818 | 828 |
819 %make these warnings if possible | 829 %make these warnings if possible |
820 | 830 |
821 It is a static warning if an instance method $m_1$ overrides (\ref{inheritanceA ndOverriding}) an instance member $m_2$ and $m_1$ has a greater number of requi red parameters than $m_2$. It is a static warning if an instance method $m_1$ ov errides an instance member $m_2$ and $m_1$ has fewer positional parameters tha n $m_2$. It is a static warning if an instance method $m_1$ overrides an insta nce member $m_2$ and $m_1$ does not declare all the named parameters declared b y $m_2$. | 831 It is a static warning if an instance method $m_1$ overrides (\ref{inheritanceA ndOverriding}) an instance member $m_2$ and $m_1$ has a greater number of requi red parameters than $m_2$. It is a static warning if an instance method $m_1$ ov errides an instance member $m_2$ and $m_1$ has fewer positional parameters tha n $m_2$. It is a static warning if an instance method $m_1$ overrides an insta nce member $m_2$ and $m_1$ does not declare all the named parameters declared b y $m_2$. |
822 | 832 |
823 % not quite right. It should be ok to override a method that requires N paramete rs with one that requires M < N but accepts the others as optional. | 833 % not quite right. It should be ok to override a method that requires N paramete rs with one that requires M < N but accepts the others as optional. |
824 | 834 |
825 It is a static warning if an instance method $m_1$ overrides an instance member $m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$. It is a stati c warning if an instance method $m_1$ overrides an instance member $m_2$, the s ignature of $m_2$ explicitly specifies a default value for a formal parameter $p $ and the signature of $m_1$ specifies a different default value for $p$. It is a static warning if a class $C$ declares an instance method named $n$ and has a setter named $n=$. It is a static warning if a class $C$ declares an instance me thod named $n$ and an accessible static member named $n$ is declared in a superc lass of $C$. | 835 It is a static warning if an instance method $m_1$ overrides an instance member $m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$. It is a stati c warning if an instance method $m_1$ overrides an instance member $m_2$, the s ignature of $m_2$ explicitly specifies a default value for a formal parameter $p $ and the signature of $m_1$ implies a different default value for $p$. It is a static warning if a class $C$ declares an instance method named $n$ and has a se tter named $n=$. It is a static warning if a class $C$ declares an instance meth od named $n$ and an accessible static member named $n$ is declared in a supercla ss of $C$. |
826 | 836 |
827 % Works. If the name is public, no issue. If it's private, if a subclass has a c onflicting inst var, it either is in the same lib and will be flagged, or is in another and is not an issue. | 837 % Works. If the name is public, no issue. If it's private, if a subclass has a c onflicting inst var, it either is in the same lib and will be flagged, or is in another and is not an issue. |
828 | 838 |
829 | 839 |
830 \subsubsection{Operators} | 840 \subsubsection{Operators} |
831 \label{operators} | 841 \label{operators} |
832 | 842 |
833 {\em Operators} are instance methods with special names. | 843 {\em Operators} are instance methods with special names. |
834 | 844 |
835 \begin{grammar} | 845 \begin{grammar} |
(...skipping 87 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
923 \end{grammar} | 933 \end{grammar} |
924 | 934 |
925 If no return type is specified, the return type of the setter is \DYNAMIC{}. | 935 If no return type is specified, the return type of the setter is \DYNAMIC{}. |
926 | 936 |
927 A setter definition that is prefixed with the \STATIC{} modifier defines a stati c setter. Otherwise, it defines an instance setter. The name of a setter is obt ained by appending the string `=' to the identifier given in its signature. Th e effect of a static setter declaration in class $C$ is to add an instance sette r with the same name and signature to the \code{Type} object for class $C$ that forwards (\ref{functionDeclarations}) to the static setter. | 937 A setter definition that is prefixed with the \STATIC{} modifier defines a stati c setter. Otherwise, it defines an instance setter. The name of a setter is obt ained by appending the string `=' to the identifier given in its signature. Th e effect of a static setter declaration in class $C$ is to add an instance sette r with the same name and signature to the \code{Type} object for class $C$ that forwards (\ref{functionDeclarations}) to the static setter. |
928 | 938 |
929 \commentary{Hence, a setter name can never conflict with, override or be overrid den by a getter or method.} | 939 \commentary{Hence, a setter name can never conflict with, override or be overrid den by a getter or method.} |
930 | 940 |
931 The instance setters of a class $C$ are those instance setters declared by $C$ e ither implicitly or explicitly, and the instance setters inherited by $C$ from i ts superclass. The static setters of a class $C$ are those static setters declar ed by $C$. | 941 The instance setters of a class $C$ are those instance setters declared by $C$ e ither implicitly or explicitly, and the instance setters inherited by $C$ from i ts superclass. The static setters of a class $C$ are those static setters declar ed by $C$. |
932 | 942 |
933 It is a compile-time error if a setter's formal parameter list does not consist of exactly one required formal parameter $p$. \rationale{We could enforce this via the grammar, but we`d have to specify the evaluation rules in that case.} | 943 It is a compile-time error if a setter's formal parameter list does not consist of exactly one required formal parameter $p$. \rationale{We could enforce this via the grammar, but we'd have to specify the evaluation rules in that case.} |
934 | 944 |
935 %It is a compile-time error if a class has both a setter and a method with the s ame name. This restriction holds regardless of whether the setter is defined exp licitly or implicitly, or whether the setter or the method are inherited or not. | 945 %It is a compile-time error if a class has both a setter and a method with the s ame name. This restriction holds regardless of whether the setter is defined exp licitly or implicitly, or whether the setter or the method are inherited or not. |
936 | 946 |
937 It is a static warning if a setter declares a return type other than \VOID{}. | 947 It is a static warning if a setter declares a return type other than \VOID{}. |
938 It is a static warning if a setter $m_1$ overrides (\ref{inheritanceAndOverridi ng}) a setter $m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$. It is a static warning if a class has a setter named $v=$ with argument type $T $ and a getter named $v$ with return type $S$, and $T$ may not be assigned to $S $. | 948 It is a static warning if a setter $m_1$ overrides (\ref{inheritanceAndOverridi ng}) a setter $m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$. It is a static warning if a class has a setter named $v=$ with argument type $T $ and a getter named $v$ with return type $S$, and $T$ may not be assigned to $S $. |
939 | 949 |
940 It is a static warning if a class declares a static setter named $v=$ and also has a non-static member named $v$. It is a static warning if a class $C$ declare s an instance setter named $v=$ and an accessible static member named $v=$ or $v $ is declared in a superclass of $C$. | 950 It is a static warning if a class declares a static setter named $v=$ and also has a non-static member named $v$. It is a static warning if a class $C$ declare s an instance setter named $v=$ and an accessible static member named $v=$ or $v $ is declared in a superclass of $C$. |
941 | 951 |
942 These warnings must be issued regardless of whether the getters or setters are d eclared explicitly or implicitly. | 952 These warnings must be issued regardless of whether the getters or setters are d eclared explicitly or implicitly. |
943 | 953 |
(...skipping 115 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
1059 \begin{grammar} | 1069 \begin{grammar} |
1060 {\bf constructorSignature:} | 1070 {\bf constructorSignature:} |
1061 identifier (`{\escapegrammar .}' identifier)? formalParameterList | 1071 identifier (`{\escapegrammar .}' identifier)? formalParameterList |
1062 . | 1072 . |
1063 \end{grammar} | 1073 \end{grammar} |
1064 | 1074 |
1065 A {\em constructor parameter list} is a parenthesized, comma-separated list of f ormal constructor parameters. A {\em formal constructor parameter} is either a f ormal parameter (\ref{formalParameters}) or an initializing formal. An {\em init ializing formal} has the form \code{\THIS{}.id}, where \code{id} is the name of an instance variable of the immediately enclosing class. It is a compile-time e rror if \code{id} is not an instance variable of the immediately enclosing class . It is a compile-time error if an initializing formal is used by a function oth er than a non-redirecting generative constructor. | 1075 A {\em constructor parameter list} is a parenthesized, comma-separated list of f ormal constructor parameters. A {\em formal constructor parameter} is either a f ormal parameter (\ref{formalParameters}) or an initializing formal. An {\em init ializing formal} has the form \code{\THIS{}.id}, where \code{id} is the name of an instance variable of the immediately enclosing class. It is a compile-time e rror if \code{id} is not an instance variable of the immediately enclosing class . It is a compile-time error if an initializing formal is used by a function oth er than a non-redirecting generative constructor. |
1066 | 1076 |
1067 If an explicit type is attached to the initializing formal, that is its static t ype. Otherwise, the type of an initializing formal named \code{id} is $T_{id}$, where $T_{id}$ is the type of the field named \code{id} in the immediately enclo sing class. It is a static warning if the static type of \code{id} is not assign able to $T_{id}$. | 1077 If an explicit type is attached to the initializing formal, that is its static t ype. Otherwise, the type of an initializing formal named \code{id} is $T_{id}$, where $T_{id}$ is the type of the field named \code{id} in the immediately enclo sing class. It is a static warning if the static type of \code{id} is not assign able to $T_{id}$. |
1068 | 1078 |
1069 Using an initializing formal \code{\THIS{}.id} in a formal parameter list does n ot introduce a formal parameter name into the scope of the constructor. However, the initializing formal does effect the type of the constructor function exactl y as if a formal parameter named \code{id} of the same type were introduced in the same position. | 1079 Using an initializing formal \code{\THIS{}.id} in a formal parameter list does n ot introduce a formal parameter name into the scope of the constructor. However, the initializing formal does effect the type of the constructor function exactl y as if a formal parameter named \code{id} of the same type were introduced in the same position. |
1070 | 1080 |
1071 Initializing formals are executed during the execution of generative constructor s detailed below. Executing an initializing formal \code{\THIS{}.id} causes the field \code{id} of the immediately surrounding class to be assigned the value o f the corresponding actual parameter, unless $id$ is a final variable that has a lready been initialized, in which case a runtime error occurs. | 1081 Initializing formals are executed during the execution of generative constructor s detailed below. Executing an initializing formal \code{\THIS{}.id} causes the field \code{id} of the immediately surrounding class to be assigned the value o f the corresponding actual parameter, unless $id$ is a final variable that has a lready been initialized, in which case a runtime error occurs. |
1072 | 1082 |
1073 | 1083 |
1074 \commentary{ | 1084 \commentary{ |
1075 The above rule allows initializing formals to be used as optional parameters: | 1085 The above rule allows initializing formals to be used as optional parameters: |
1076 } | 1086 } |
1077 | 1087 |
1078 \begin{dartCode} | 1088 \begin{dartCode} |
1079 class A \{ | 1089 class A \{ |
(...skipping 484 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
1564 Whether an override is legal or not is described elsewhere in this specification (see \ref{instanceMethods}, \ref{getters} and \ref{setters}). | 1574 Whether an override is legal or not is described elsewhere in this specification (see \ref{instanceMethods}, \ref{getters} and \ref{setters}). |
1565 | 1575 |
1566 \commentary{For example getters may not legally override methods and vice versa. Setters never override methods or getters, and vice versa, because their names always differ. | 1576 \commentary{For example getters may not legally override methods and vice versa. Setters never override methods or getters, and vice versa, because their names always differ. |
1567 } | 1577 } |
1568 | 1578 |
1569 \rationale{ | 1579 \rationale{ |
1570 It is nevertheless convenient to define the override relation between members in this way, so that we can concisely describe the illegal cases. | 1580 It is nevertheless convenient to define the override relation between members in this way, so that we can concisely describe the illegal cases. |
1571 } | 1581 } |
1572 | 1582 |
1573 \commentary{ | 1583 \commentary{ |
1574 Note that instance variables do not participate in the override relation, but th e getters and setters they induce do. Also, getters don`t override setters and v ice versa. Finally, static members never override anything. | 1584 Note that instance variables do not participate in the override relation, but th e getters and setters they induce do. Also, getters don't override setters and v ice versa. Finally, static members never override anything. |
1575 } | 1585 } |
1576 | 1586 |
1577 It is a static warning if a non-abstract class inherits an abstract method. | 1587 It is a static warning if a non-abstract class inherits an abstract method. |
1578 | 1588 |
1579 \commentary { | 1589 \commentary { |
1580 For convenience, here is a summary of the relevant rules. Remember that this is not normative. The controlling language is in the relevant sections of the speci fication. | 1590 For convenience, here is a summary of the relevant rules. Remember that this is not normative. The controlling language is in the relevant sections of the speci fication. |
1581 | 1591 |
1582 \begin{enumerate} | 1592 \begin{enumerate} |
1583 | 1593 |
1584 \item There is only one namespace for getters, setters, methods and constructors (\ref{scoping}). A field $f$ introduces a getter $f$ and a non-final field $f$ also introduces a setter $f=$ (\ref{instanceVariables}, \ref{staticVariables}). When we speak of members here, we mean accessible fields, getters, setters and m ethods (\ref{classes}). | 1594 \item There is only one namespace for getters, setters, methods and constructors (\ref{scoping}). A field $f$ introduces a getter $f$ and a non-final field $f$ also introduces a setter $f=$ (\ref{instanceVariables}, \ref{staticVariables}). When we speak of members here, we mean accessible fields, getters, setters and m ethods (\ref{classes}). |
(...skipping 28 matching lines...) Expand all Loading... | |
1613 \end{itemize} (\ref{interfaceInheritanceAndOverriding}) | 1623 \end{itemize} (\ref{interfaceInheritanceAndOverriding}) |
1614 \item Rule \ref{typeSigAssignable} applies to interfaces as well as classes (\ ref{interfaceInheritanceAndOverriding}). | 1624 \item Rule \ref{typeSigAssignable} applies to interfaces as well as classes (\ ref{interfaceInheritanceAndOverriding}). |
1615 \item It is a static warning if a concrete class does not have an implementatio n for a method in any of its superinterfaces unless it declares its own \cd{n oSuchMethod} method (\ref{superinterfaces}). | 1625 \item It is a static warning if a concrete class does not have an implementatio n for a method in any of its superinterfaces unless it declares its own \cd{n oSuchMethod} method (\ref{superinterfaces}). |
1616 \item The identifier of a named constructor cannot be the same as the name of a member declared (as opposed to inherited) in the same class (\ref{constructors}) . | 1626 \item The identifier of a named constructor cannot be the same as the name of a member declared (as opposed to inherited) in the same class (\ref{constructors}) . |
1617 \end{enumerate} | 1627 \end{enumerate} |
1618 } | 1628 } |
1619 | 1629 |
1620 | 1630 |
1621 %Can we have abstract getters and setters? | 1631 %Can we have abstract getters and setters? |
1622 | 1632 |
1623 \subsection{Superinterfaces} | 1633 \subsection{ Superinterfaces} |
1624 \label{superinterfaces} | 1634 \label{superinterfaces} |
1625 % what about rules about classes that fail to implement their interfaces? | 1635 % what about rules about classes that fail to implement their interfaces? |
1626 | 1636 |
1627 A class has a set of direct superinterfaces. This set includes the interface of its superclass and the interfaces specified in the the \IMPLEMENTS{} clause of the class. | 1637 A class has a set of direct superinterfaces. This set includes the interface of its superclass and the interfaces specified in the the \IMPLEMENTS{} clause of the class. |
1628 % and any superinterfaces specified by interface injection (\ref{interfaceInject ion}). \Q{The latter needs to be worded carefully - when do interface injection clauses execute and in what scope?} | 1638 % and any superinterfaces specified by interface injection (\ref{interfaceInject ion}). \Q{The latter needs to be worded carefully - when do interface injection clauses execute and in what scope?} |
1629 | 1639 |
1630 \begin{grammar} | 1640 \begin{grammar} |
1631 {\bf interfaces:} | 1641 {\bf interfaces:} |
1632 \IMPLEMENTS{} typeList | 1642 \IMPLEMENTS{} typeList |
1633 . | 1643 . |
(...skipping 265 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
1899 \STATIC{} \CONST{} E id$_{n-1}$ = const E(n - 1); | 1909 \STATIC{} \CONST{} E id$_{n-1}$ = const E(n - 1); |
1900 \STATIC{} \CONST{} List$<$E$>$ values = const $<$E$>$[id$_0 \ldots $ id$_{n-1} $]; | 1910 \STATIC{} \CONST{} List$<$E$>$ values = const $<$E$>$[id$_0 \ldots $ id$_{n-1} $]; |
1901 String toString() =$>$ \{ 0: `E.id$_0$', $\ldots$, n-1: `E.id$_{n-1}$'\}[index ] | 1911 String toString() =$>$ \{ 0: `E.id$_0$', $\ldots$, n-1: `E.id$_{n-1}$'\}[index ] |
1902 \} | 1912 \} |
1903 \end{dartCode} | 1913 \end{dartCode} |
1904 | 1914 |
1905 \commentary { | 1915 \commentary { |
1906 It is also a compile-time error to subclass, mix-in or implement an enum or to e xplicitly instantiate an enum. These restrictions are given in normative form i n sections \ref{superclasses}, \ref{superinterfaces}, \ref{mixinApplication} and \ref{instanceCreation} as appropriate. | 1916 It is also a compile-time error to subclass, mix-in or implement an enum or to e xplicitly instantiate an enum. These restrictions are given in normative form i n sections \ref{superclasses}, \ref{superinterfaces}, \ref{mixinApplication} and \ref{instanceCreation} as appropriate. |
1907 } | 1917 } |
1908 | 1918 |
1909 | |
1910 | |
1911 \section{Generics} | 1919 \section{Generics} |
1912 \label{generics} | 1920 \label{generics} |
1913 | 1921 |
1914 A class declaration (\ref{classes}) or type alias (\ref{typedef}) | 1922 A class declaration (\ref{classes}) or type alias (\ref{typedef}) |
1915 $G$ may be {\em generic}, that is, $G$ may have formal type parameters declared. A generic declaration induces a family of declarations, one for each set of act ual type parameters provided in the program. | 1923 $G$ may be {\em generic}, that is, $G$ may have formal type parameters declared. A generic declaration induces a family of declarations, one for each set of act ual type parameters provided in the program. |
1916 | 1924 |
1917 \begin{grammar} | 1925 \begin{grammar} |
1918 {\bf typeParameter:} | 1926 {\bf typeParameter:} |
1919 metadata identifier (\EXTENDS{} type)? | 1927 metadata identifier (\EXTENDS{} type)? |
1920 . | 1928 . |
(...skipping 203 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
2124 \item Both $c_1$ and $c_2$ represent a NaN value with the same underlying bit pattern. | 2132 \item Both $c_1$ and $c_2$ represent a NaN value with the same underlying bit pattern. |
2125 \end{itemize} | 2133 \end{itemize} |
2126 OR | 2134 OR |
2127 \item $c_1$ and $c_2$ are constant lists that are defined to be identical in th e specification of literal list expressions (\ref{lists}), OR | 2135 \item $c_1$ and $c_2$ are constant lists that are defined to be identical in th e specification of literal list expressions (\ref{lists}), OR |
2128 \item $c_1$ and $c_2$ are constant maps that are defined to be identical in the specification of literal map expressions (\ref{maps}), OR | 2136 \item $c_1$ and $c_2$ are constant maps that are defined to be identical in the specification of literal map expressions (\ref{maps}), OR |
2129 \item $c_1$ and $c_2$ are constant objects of the same class $C$ and each membe r field of $c_1$ is identical to the corresponding field of $c_2$. OR | 2137 \item $c_1$ and $c_2$ are constant objects of the same class $C$ and each membe r field of $c_1$ is identical to the corresponding field of $c_2$. OR |
2130 \item $c_1$ and $c_2$ are the same object. | 2138 \item $c_1$ and $c_2$ are the same object. |
2131 \end{itemize} | 2139 \end{itemize} |
2132 | 2140 |
2133 \commentary{ | 2141 \commentary{ |
2134 The definition of \cd{identity} for doubles differs from that of equality in tha t a NaN is equal to itself, and that negative and positive zero are distinct. | 2142 The definition of \cd{identity} for doubles differs from that of equality in tha t a NaN is identical to itself, and that negative and positive zero are distinct . |
2135 } | 2143 } |
2136 | 2144 |
2137 \rationale{ | 2145 \rationale{ |
2138 The definition of equality for doubles is dictated by the IEEE 754 standard, whi ch posits that NaNs do not obey the law of reflexivity. Given that hardware imp lements these rules, it is necessary to support them for reasons of efficiency. | 2146 The definition of equality for doubles is dictated by the IEEE 754 standard, whi ch posits that NaNs do not obey the law of reflexivity. Given that hardware imp lements these rules, it is necessary to support them for reasons of efficiency. |
2139 | 2147 |
2140 The definition of identity is not constrained in the same way. Instead, it assum es that bit-identical doubles are identical. | 2148 The definition of identity is not constrained in the same way. Instead, it assum es that bit-identical doubles are identical. |
2141 | 2149 |
2142 The rules for identity make it impossible for a Dart programmer to observe wheth er a boolean or numerical value is boxed or unboxed. | 2150 The rules for identity make it impossible for a Dart programmer to observe wheth er a boolean or numerical value is boxed or unboxed. |
2143 } | 2151 } |
2144 | 2152 |
(...skipping 552 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
2697 {\bf throwExpression:} | 2705 {\bf throwExpression:} |
2698 \THROW{} expression | 2706 \THROW{} expression |
2699 . | 2707 . |
2700 | 2708 |
2701 {\bf throwExpressionWithoutCascade:} | 2709 {\bf throwExpressionWithoutCascade:} |
2702 \THROW{} expressionWithoutCascade | 2710 \THROW{} expressionWithoutCascade |
2703 . | 2711 . |
2704 | 2712 |
2705 \end{grammar} | 2713 \end{grammar} |
2706 | 2714 |
2707 The {\em current exception} is the last unhandled exception thrown. | 2715 The {\em current exception} is the last exception raised and not subsequently c aught at a given moment during runtime. |
2708 | 2716 |
2709 Evaluation of a throw expression of the form \code{\THROW{} $e$;} proceeds as follows: | 2717 Evaluation of a throw expression of the form \code{\THROW{} $e$;} proceeds as follows: |
2710 | 2718 |
2711 The expression $e$ is evaluated yielding a value $v$. If $v$ evaluates to \NULL{ }, then a \code{NullThrownError} is thrown. Otherwise, control is transferred to the nearest dynamically enclosing exception handler (\ref{try}), with the curre nt exception set to $v$. | 2719 The expression $e$ is evaluated yielding a value $v$. |
2712 | 2720 |
2713 \commentary{ | 2721 \commentary{ |
2714 There is no requirement that the expression $e$ evaluate to a special kind of ex ception or error object. | 2722 There is no requirement that the expression $e$ evaluate to a special kind of ex ception or error object. |
2715 } | 2723 } |
2716 | 2724 |
2725 If $e$ evaluates to \NULL{} (\ref{null}), then a \code{NullThrownError} is throw n. Otherwise the current exception is set to $v$ and the current return value (\ ref{return}) becomes undefined. | |
2726 | |
2727 \rationale{The current exception and the current return value must never be simu ltaneously defined, as they represent mutually exclusive options for exiting the current function. | |
2728 } | |
2729 | |
2730 Let $f$ be the immediately enclosing function. | |
2731 | |
2732 If $f$ is synchronous (\ref{functions}), control is transferred to the nearest d ynamically enclosing exception handler. | |
2733 | |
2734 \commentary{ | |
2735 If $f$ is marked \SYNC* then a dynamically enclosing exception handler encloses the call to \code{moveNext()} that initiated the evaluation of the throw express ion. | |
2736 } | |
2737 | |
2738 If $f$ is asynchronous then if there is a dynamically enclosing exception handl er $h$ (\ref{try}) introduced by the current activation, control is transferred to $h$, otherwise $f$ terminates. | |
2739 | |
2740 \rationale{ | |
2741 The rules for where a thrown exception will be handled must necessarily differ b etween the synchronous and asynchronous cases. Asynchronous functions cannot tra nsfer control to an exception handler defined outside themselves. Asynchronous generators post exceptions to their stream. Other asynchronous functions report exceptions via their future. | |
2742 } | |
2743 | |
2717 If the object being thrown is an instance of class \code{Error} or a subclass th ereof, its \code{stackTrace} getter will return the stack trace current at the p oint where the the object was first thrown. | 2744 If the object being thrown is an instance of class \code{Error} or a subclass th ereof, its \code{stackTrace} getter will return the stack trace current at the p oint where the the object was first thrown. |
2718 | 2745 |
2719 The static type of a throw expression is $\bot$. | 2746 The static type of a throw expression is $\bot$. |
2720 | 2747 |
2721 | 2748 |
2722 \subsection{ Function Expressions} | 2749 \subsection{ Function Expressions} |
2723 \label{functionExpressions} | 2750 \label{functionExpressions} |
2724 | 2751 |
2725 A {\em function literal} is an object that encapsulates an executable unit of co de. | 2752 A {\em function literal} is an object that encapsulates an executable unit of co de. |
2726 | 2753 |
2727 \begin{grammar} | 2754 \begin{grammar} |
2728 {\bf functionExpression:} | 2755 {\bf functionExpression:} |
2729 formalParameterList functionExpressionBody | 2756 formalParameterList functionBody |
2730 . | |
2731 | |
2732 | |
2733 {\bf functionExpressionBody:} | |
2734 `={\escapegrammar \gt}' expression; | |
2735 block | |
2736 . | 2757 . |
2737 \end{grammar} | 2758 \end{grammar} |
2738 | 2759 |
2739 The class of a function literal implements the built-in class \code{Function}. | 2760 The class of a function literal implements the built-in class \code{Function}. |
2740 %Invoking the getter \code{runtimeType} on a function literal returns the \code{ Type} object that is the value of the expression \code{Function}. | 2761 %Invoking the getter \code{runtimeType} on a function literal returns the \code{ Type} object that is the value of the expression \code{Function}. |
2741 % not necessarily | 2762 % not necessarily |
2742 | 2763 |
2743 | 2764 |
2744 %Q{Can anyone implement it? Then we should define things via call} | 2765 %Q{Can anyone implement it? Then we should define things via call} |
2745 | 2766 |
2746 The static type of a function literal of the form | 2767 The static type of a function literal of the form |
2747 | 2768 |
2748 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k} = d_k]) => e$ | 2769 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k} = d_k]) => e$ |
2770 is | |
2749 | 2771 |
2750 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarro w T_0$, where $T_0$ is the static type of $e$. In any case where $T_i, 1 \le i \ le n+k$, is not specified, it is considered to have been specified as \DYNAMIC{ }. | 2772 $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow T _0$, where $T_0$ is the static type of $e$. |
2773 | |
2774 The static type of a function literal of the form | |
2775 | |
2776 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k} = d_k])$ \ASYNC{} $=> e$ | |
2777 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarro w Future<T_0>$, where $T_0$ is the static type of $e$. | |
2751 | 2778 |
2752 The static type of a function literal of the form | 2779 The static type of a function literal of the form |
2753 | 2780 |
2754 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots, T_{n+k}$ $x_ {n+k} : d_k\}) => e$ | 2781 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots, T_{n+k}$ $x_ {n+k} : d_k\}) => e$ |
2782 is | |
2755 | 2783 |
2756 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightar row T_0$, where $T_0$ is the static type of $e$. In any case where $T_i, 1 \le i \le n+k$, is not specified, it is considered to have been specified as \DYNAMI C{}. | 2784 $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightarrow T_0$, where $T_0$ is the static type of $e$. |
2785 | |
2786 The static type of a function literal of the form | |
2787 | |
2788 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots, T_{n+k}$ $x_ {n+k} : d_k\})$ \ASYNC{} $=> e$ | |
2789 | |
2790 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightar row Future<T_0>$, where $T_0$ is the static type of $e$. | |
2757 | 2791 |
2758 The static type of a function literal of the form | 2792 The static type of a function literal of the form |
2759 | 2793 |
2760 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k}= d_k])\{s\}$ | 2794 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k}= d_k])\{s\}$ |
2761 | 2795 |
2762 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarro w \DYNAMIC{}$. In any case where $T_i, 1 \le i \le n+k$, is not specified, it i s considered to have been specified as \DYNAMIC{}. | 2796 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarro w \DYNAMIC{}$. |
2763 | 2797 |
2764 The static type of a function literal of the form | 2798 The static type of a function literal of the form |
2765 | 2799 |
2766 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots, T_{n+k}$ $x_ {n+k} : d_k\})\{s\}$ | 2800 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k}= d_k])$ $ \ASYNC{}$ $\{s\}$ |
2801 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarro w Future$. | |
2767 | 2802 |
2768 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightar row \DYNAMIC{}$. In any case where $T_i, 1 \le i \le n+k$, is not specified, it is considered to have been specified as \DYNAMIC{}. | 2803 The static type of a function literal of the form |
2769 | 2804 |
2770 %** Now that declared return types are precluded, do we need some better return type rule for (x){s} and friends? | 2805 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k}= d_k])$ $ \ASYNC*{}$ $\{s\}$ |
2806 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarro w Stream$. | |
2771 | 2807 |
2808 The static type of a function literal of the form | |
2809 | |
2810 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k}= d_k])$ $ \SYNC*{}$ $\{s\}$ | |
2811 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarro w Iterable$. | |
2812 | |
2813 | |
2814 The static type of a function literal of the form | |
2815 | |
2816 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{ n+k}= d_k])\{s\}$ | |
2817 | |
2818 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarro w \DYNAMIC{}$. | |
2819 | |
2820 | |
2821 The static type of a function literal of the form | |
2822 | |
2823 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots, T_{n+k}$ $x_ {n+k} : d_k\})$ $\ASYNC{}$ $\{s\}$ | |
2824 | |
2825 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightar row Future{}$. | |
2826 | |
2827 The static type of a function literal of the form | |
2828 | |
2829 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots, T_{n+k}$ $x_ {n+k} : d_k\})$ $\ASYNC*{}$ $\{s\}$ | |
2830 | |
2831 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightar row Stream{}$. | |
2832 | |
2833 The static type of a function literal of the form | |
2834 | |
2835 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots, T_{n+k}$ $x_ {n+k} : d_k\})$ $\SYNC*{}$ $\{s\}$ | |
2836 | |
2837 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightar row Iterable{}$. | |
2838 | |
2839 In all of the above cases, whenever $T_i, 1 \le i \le n+k$, is not specified, it is considered to have been specified as \DYNAMIC{}. | |
2772 | 2840 |
2773 | 2841 |
2774 \subsection{ This} | 2842 \subsection{ This} |
2775 \label{this} | 2843 \label{this} |
2776 | 2844 |
2777 The reserved word \THIS{} denotes the target of the current instance member invo cation. | 2845 The reserved word \THIS{} denotes the target of the current instance member invo cation. |
2778 | 2846 |
2779 \begin{grammar} | 2847 \begin{grammar} |
2780 {\bf thisExpression:} | 2848 {\bf thisExpression:} |
2781 \THIS{} | 2849 \THIS{} |
2782 . | 2850 . |
2783 \end{grammar} | 2851 \end{grammar} |
2784 | 2852 |
2785 The static type of \THIS{} is the interface of the immediately enclosing class. | 2853 The static type of \THIS{} is the interface of the immediately enclosing class. |
2786 | 2854 |
2787 \commentary{ | 2855 \commentary{ |
2788 We do not support self-types at this point. | 2856 We do not support self-types at this point. |
2789 } | 2857 } |
2790 | 2858 |
2791 It is a compile-time error if \THIS{} appears in a top-level function or variabl e initializer, in a factory constructor, or in a static method or variable init ializer, or in the initializer of an instance variable. | 2859 It is a compile-time error if \THIS{} appears, implicitly or explicitly, in a t op-level function or variable initializer, in a factory constructor, or in a st atic method or variable initializer, or in the initializer of an instance variab le. |
2792 | 2860 |
2793 \subsection{ Instance Creation} | 2861 \subsection{ Instance Creation} |
2794 \label{instanceCreation} | 2862 \label{instanceCreation} |
2795 | 2863 |
2796 Instance creation expressions invoke constructors to produce instances. | 2864 Instance creation expressions invoke constructors to produce instances. |
2797 | 2865 |
2798 %It is a compile-time error if any of the type arguments to a constructor of a g eneric type invoked by a new expression or a constant object expression do not d enote types in the enclosing lexical scope. | 2866 %It is a compile-time error if any of the type arguments to a constructor of a g eneric type invoked by a new expression or a constant object expression do not d enote types in the enclosing lexical scope. |
2799 | 2867 |
2800 %It is a compile-time error if a constructor of a non-generic type invoked by a new expression or a constant object expression is passed any type arguments. It is a compile-time error if a constructor of a generic type with $n$ type paramet ers invoked by a new expression or a constant object expression is passed $m$ ty pe arguments where $m \ne n$, or if any of its type arguments is misconstructed (\ref{parameterizedTypes}). | 2868 %It is a compile-time error if a constructor of a non-generic type invoked by a new expression or a constant object expression is passed any type arguments. It is a compile-time error if a constructor of a generic type with $n$ type paramet ers invoked by a new expression or a constant object expression is passed $m$ ty pe arguments where $m \ne n$, or if any of its type arguments is misconstructed (\ref{parameterizedTypes}). |
2801 | 2869 |
(...skipping 54 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
2856 If $T$ is a parameterized type (\ref{parameterizedTypes}) $S<U_1, \ldots, U_m>$ , let $R = S$. | 2924 If $T$ is a parameterized type (\ref{parameterizedTypes}) $S<U_1, \ldots, U_m>$ , let $R = S$. |
2857 %It is a | 2925 %It is a |
2858 %compile-time CHANGED | 2926 %compile-time CHANGED |
2859 %runtime type | 2927 %runtime type |
2860 %error if $S$ is not a generic (\ref{generics}) type with $m$ type parameters. | 2928 %error if $S$ is not a generic (\ref{generics}) type with $m$ type parameters. |
2861 If $T$ is not a parameterized type, let $R = T$. | 2929 If $T$ is not a parameterized type, let $R = T$. |
2862 Furthermore, if $e$ is of the form \NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n +1}, \ldots , x_{n+k}: a_{n+k})$ then let $q$ be the constructor $T.id$, other wise let $q$ be the constructor $T$. | 2930 Furthermore, if $e$ is of the form \NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n +1}, \ldots , x_{n+k}: a_{n+k})$ then let $q$ be the constructor $T.id$, other wise let $q$ be the constructor $T$. |
2863 | 2931 |
2864 If $R$ is a generic with $l = m$ type parameters then | 2932 If $R$ is a generic with $l = m$ type parameters then |
2865 \begin{itemize} | 2933 \begin{itemize} |
2866 \item $T$ is not a parameterized type, then for $ i \in 1 .. l$, let $V_i = \D YNAMIC{}$. | 2934 \item If $T$ is not a parameterized type, then for $ i \in 1 .. l$, let $V_i = \DYNAMIC{}$. |
2867 \item If $T$ is a parameterized type then let $V_i = U_i$ for $ i \in 1 .. m$. | 2935 \item If $T$ is a parameterized type then let $V_i = U_i$ for $ i \in 1 .. m$. |
2868 \end{itemize} | 2936 \end{itemize} |
2869 | 2937 |
2870 If $R$ is a generic with $l \ne m$ type parameters then for $ i \in 1 .. l$, let $V_i = \DYNAMIC{}$. In any other case, let $V_i = U_i$ for $ i \in 1 .. m$. | 2938 If $R$ is a generic with $l \ne m$ type parameters then for $ i \in 1 .. l$, let $V_i = \DYNAMIC{}$. In any other case, let $V_i = U_i$ for $ i \in 1 .. m$. |
2871 | 2939 |
2872 Evaluation of $e$ proceeds as follows: | 2940 Evaluation of $e$ proceeds as follows: |
2873 | 2941 |
2874 First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k} : a_{n+k})$ is evaluated. | 2942 First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k} : a_{n+k})$ is evaluated. |
2875 | 2943 |
2876 If $T$ is a deferred type with prefix $p$, then if $p$ has not been successfully loaded, a dynamic error occurs. | 2944 If $T$ is a deferred type with prefix $p$, then if $p$ has not been successfully loaded, a dynamic error occurs. |
(...skipping 159 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
3036 | 3104 |
3037 \commentary{ | 3105 \commentary{ |
3038 As discussed in section \ref{errorsAndWarnings}, the handling of a suspended iso late is the responsibility of the embedder. | 3106 As discussed in section \ref{errorsAndWarnings}, the handling of a suspended iso late is the responsibility of the embedder. |
3039 } | 3107 } |
3040 | 3108 |
3041 | 3109 |
3042 | 3110 |
3043 \subsection{ Function Invocation} | 3111 \subsection{ Function Invocation} |
3044 \label{functionInvocation} | 3112 \label{functionInvocation} |
3045 | 3113 |
3046 Function invocation occurs in the following cases: when a function expression ( \ref{functionExpressions}) is invoked (\ref{functionExpressionInvocation}), when a method (\ref{methodInvocation}), getter (\ref{topLevelGetterInvocation}, \ref {propertyExtraction}) or setter (\ref{assignment}) is invoked or when a construc tor is invoked (either via instance creation (\ref{instanceCreation}), construct or redirection (\ref{redirectingConstructors}) or super initialization). The var ious kinds of function invocation differ as to how the function to be invoked, $ f$, is determined, as well as whether \THIS{} is bound. Once $f$ has been deter mined, the formal parameters of $f$ are bound to corresponding actual arguments. The body of $f$ is then executed with the aforementioned bindings. Execution of the body terminates when the first of the following occurs: | 3114 Function invocation occurs in the following cases: when a function expression ( \ref{functionExpressions}) is invoked (\ref{functionExpressionInvocation}), when a method (\ref{methodInvocation}), getter (\ref{topLevelGetterInvocation}, \ref {propertyExtraction}) or setter (\ref{assignment}) is invoked or when a construc tor is invoked (either via instance creation (\ref{instanceCreation}), construct or redirection (\ref{redirectingConstructors}) or super initialization). The var ious kinds of function invocation differ as to how the function to be invoked, $ f$, is determined, as well as whether \THIS{} (\ref{this}) is bound. Once $f$ h as been determined, the formal parameters of $f$ are bound to corresponding actu al arguments. When the body of $f$ is executed it will be executed with the afor ementioned bindings. |
3115 | |
3116 If $f$ is marked \ASYNC{} (\ref{functions}), then a fresh instance (\ref{generat iveConstructors}) $o$ implementing the built-in class \code{Future} is associate d with the invocation and immediately returned to the caller. The body of $f$ is scheduled for execution at some future time. The future $o$ will complete when $f$ terminates. The value used to complete $o$ is the current return value (\ref {return}), if it is defined, and the current exception (\ref{throw}) otherwise. | |
3117 | |
3118 If $f$ is marked \ASYNC* (\ref{functions}), then a fresh instance $s$ implementi ng the built-in class \code{Stream} is associated with the invocation and immedi ately returned. When $s$ is listened to, execution of the body of $f$ will begin . When $f$ terminates: | |
3119 \begin{itemize} | |
3120 \item If the current return value is defined then, if $s$ has been canceled then its cancellation future is completed with \NULL{} (\ref{null}). | |
3121 \item If the current exception $x$ is defined: | |
3122 \begin{itemize} | |
3123 \item $x$ is added to $s$. | |
3124 \item If $s$ has been canceled then its cancellation future is completed with $x$ as an error. | |
3125 \end{itemize} | |
3126 \item $s$ is closed. | |
3127 \end{itemize} | |
3128 | |
3129 \rationale{ | |
3130 When an asynchronous generator's stream has been canceled, cleanup will occur in the \FINALLY{} clauses (\ref{try}) inside the generator. We choose to direct an y exceptions that occur at this time to the cancellation future rather than have them be lost. | |
3131 } | |
3132 | |
3133 If $f$ is asynchronous then, when $f$ terminates, any open stream subscriptions associated with any asynchronous for loops (\ref{asynchronousFor-in}) or yield- each statements (\ref{yieldEach}) executing within $f$ are canceled. | |
3134 | |
3135 \rationale{Such streams may be left open by for loops that were escaped when an exception was thrown within them for example. | |
3136 } | |
3137 | |
3138 If $f$ is marked \SYNC* (\ref{functions}), then a fresh instance $i$ implementin g the built-in class \code{Iterable} is associated with the invocation and immed iately returned. When iteration over the iterable is started, by getting an iter ator $j$ from the iterable and calling \code{moveNext()} on it, execution of the body of $f$ will begin. When $f$ terminates, $j$ is positioned after its last e lement, so that its current value is \NULL{} and the current call to \code{moveN ext()} on $j$ returns false, as will all further calls. | |
3139 | |
3140 If $f$ is synchronous and is not a generator (\ref{functions}) then execution of the body of $f$ begins immediately. When $f$ terminates the current return val ue is returned to the caller. | |
3141 | |
3142 | |
3143 Execution of $f$ terminates when the first of the following occurs: | |
3047 \begin{itemize} | 3144 \begin{itemize} |
3048 \item An exception is thrown and not caught within the current function activati on. | 3145 \item An exception is thrown and not caught within the current function activati on. |
3049 \item A return statement (\ref{return}) immediately nested in the body of $f$ is executed. | 3146 \item A return statement (\ref{return}) immediately nested in the body of $f$ is executed and not intercepted in a \FINALLY{} (\ref{try}) clause. |
3050 \item The last statement of the body completes execution. | 3147 \item The last statement of the body completes execution. |
3051 \end{itemize} | 3148 \end{itemize} |
3052 | 3149 |
3053 | 3150 |
3054 | 3151 |
3055 | 3152 |
3056 \subsubsection{ Actual Argument List Evaluation} | 3153 \subsubsection{ Actual Argument List Evaluation} |
3057 \label{actualArguments} | 3154 \label{actualArguments} |
3058 | 3155 |
3059 Function invocation involves evaluation of the list of actual arguments to the f unction and binding of the results to the function`s formal parameters. | 3156 Function invocation involves evaluation of the list of actual arguments to the f unction and binding of the results to the function's formal parameters. |
3060 | 3157 |
3061 \begin{grammar} | 3158 \begin{grammar} |
3062 {\bf arguments:} | 3159 {\bf arguments:} |
3063 `(' argumentList? `)' | 3160 `(' argumentList? `)' |
3064 . | 3161 . |
3065 | 3162 |
3066 {\bf argumentList:}namedArgument (`,' namedArgument)*; | 3163 {\bf argumentList:}namedArgument (`,' namedArgument)*; |
3067 % expressionList ',' spreadArgument; | 3164 % expressionList ',' spreadArgument; |
3068 expressionList (`,' namedArgument)* | 3165 expressionList (`,' namedArgument)* |
3069 % spreadArgument | 3166 % spreadArgument |
(...skipping 96 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
3166 | 3263 |
3167 \commentary{ | 3264 \commentary{ |
3168 The implication of this definition, and the other definitions involving the meth od \code{call()}, is that user defined types can be used as function values prov ided they define a \CALL{} method. The method \CALL{} is special in this regard. The signature of the \CALL{} method determines the signature used when using th e object via the built-in invocation syntax. | 3265 The implication of this definition, and the other definitions involving the meth od \code{call()}, is that user defined types can be used as function values prov ided they define a \CALL{} method. The method \CALL{} is special in this regard. The signature of the \CALL{} method determines the signature used when using th e object via the built-in invocation syntax. |
3169 } | 3266 } |
3170 | 3267 |
3171 It is a static warning if the static type $F$ of $e_f$ may not be assigned to a function type. If $F$ is not a function type, the static type of $i$ is \DYNAMI C{}. Otherwise | 3268 It is a static warning if the static type $F$ of $e_f$ may not be assigned to a function type. If $F$ is not a function type, the static type of $i$ is \DYNAMI C{}. Otherwise |
3172 the static type of $i$ is the declared return type of $F$. | 3269 the static type of $i$ is the declared return type of $F$. |
3173 %\item Let $T_i$ be the static type of $a_i, i \in 1 .. n+k$. It is a static war ning if $F$ is not a supertype of $(T_1, \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldot s, T_{n+k}$ $x_{n+k}]) \to \bot$. | 3270 %\item Let $T_i$ be the static type of $a_i, i \in 1 .. n+k$. It is a static war ning if $F$ is not a supertype of $(T_1, \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldot s, T_{n+k}$ $x_{n+k}]) \to \bot$. |
3174 %\end{itemize} | 3271 %\end{itemize} |
3175 | 3272 |
3176 \subsection{Lookup} | 3273 \subsection{ Lookup} |
3177 | 3274 |
3178 \subsubsection{Method Lookup} | 3275 \subsubsection{Method Lookup} |
3179 \label{methodLookup} | 3276 \label{methodLookup} |
3180 | 3277 |
3181 The result of a lookup of a method $m$ in object $o$ with respect to library $L$ is the result of a lookup of method $m$ in class $C$ with respect to library $ L$, where $C$ is the class of $o$. | 3278 The result of a lookup of a method $m$ in object $o$ with respect to library $L$ is the result of a lookup of method $m$ in class $C$ with respect to library $ L$, where $C$ is the class of $o$. |
3182 | 3279 |
3183 The result of a lookup of method $m$ in class $C$ with respect to library $L$ i s: | 3280 The result of a lookup of method $m$ in class $C$ with respect to library $L$ i s: |
3184 If $C$ declares a concrete instance method named $m$ that is accessible to $L$, then that method is the result of the lookup. Otherwise, if $C$ has a superclas s $S$, then the result of the lookup is the result of looking up $m$ in $S$ wit h respect to $L$. Otherwise, we say that the method lookup has failed. | 3281 If $C$ declares a concrete instance method named $m$ that is accessible to $L$, then that method is the result of the lookup. Otherwise, if $C$ has a superclas s $S$, then the result of the lookup is the result of looking up $m$ in $S$ wit h respect to $L$. Otherwise, we say that the method lookup has failed. |
3185 | 3282 |
3186 \rationale { | 3283 \rationale { |
3187 The motivation for skipping abstract members during lookup is largely to allow s moother mixin composition. | 3284 The motivation for skipping abstract members during lookup is largely to allow s moother mixin composition. |
3188 } | 3285 } |
3189 | 3286 |
3190 | 3287 |
3191 \subsubsection{ Getter and Setter Lookup} | 3288 \subsubsection{ Getter and Setter Lookup} |
3192 \label{getterAndSetterLookup} | 3289 \label{getterAndSetterLookup} |
3193 | 3290 |
3194 The result of a lookup of a getter (respectively setter) $m$ in object $o$ with respect to library $L$ is the result of looking up getter (respectively sette r) $m$ in class $C$ with respect to $L$, where $C$ is the class of $o$. | 3291 The result of a lookup of a getter (respectively setter) $m$ in object $o$ with respect to library $L$ is the result of looking up getter (respectively sette r) $m$ in class $C$ with respect to $L$, where $C$ is the class of $o$. |
3195 | 3292 |
3196 The result of a lookup of a getter (respectively setter) $m$ in class $C$ with respect to library $L$ is: | 3293 The result of a lookup of a getter (respectively setter) $m$ in class $C$ with respect to library $L$ is: |
3197 If $C$ declares a concrete instance getter (respectively setter) named $m$ that is accessible to $L$, then that getter (respectively setter) is the result of the lookup. Otherwise, if $C$ has a superclass $S$, then the result of the looku p is the result of looking up getter (respectively setter) $m$ in $S$ with respe ct to $L$. Otherwise, we say that the lookup has failed. | 3294 If $C$ declares a concrete instance getter (respectively setter) named $m$ that is accessible to $L$, then that getter (respectively setter) is the result of the lookup. Otherwise, if $C$ has a superclass $S$, then the result of the looku p is the result of looking up getter (respectively setter) $m$ in $S$ with respe ct to $L$. Otherwise, we say that the lookup has failed. |
3198 | 3295 |
3199 \rationale { | 3296 \rationale { |
3200 The motivation for skipping abstract members during lookup is largely to allow s moother mixin composition. | 3297 The motivation for skipping abstract members during lookup is largely to allow s moother mixin composition. |
3201 } | 3298 } |
3202 | 3299 |
3203 | 3300 |
3204 \subsection{Top level Getter Invocation} | 3301 \subsection{ Top level Getter Invocation} |
3205 \label{topLevelGetterInvocation} | 3302 \label{topLevelGetterInvocation} |
3206 | 3303 |
3207 Evaluation of a top-level getter invocation $i$ of the form $m$, where $m$ is an identifier, proceeds as follows: | 3304 Evaluation of a top-level getter invocation $i$ of the form $m$, where $m$ is an identifier, proceeds as follows: |
3208 | 3305 |
3209 The getter function $m$ is invoked. The value of $i$ is the result returned by t he call to the getter function. | 3306 The getter function $m$ is invoked. The value of $i$ is the result returned by t he call to the getter function. |
3210 \commentary{ | 3307 \commentary{ |
3211 Note that the invocation is always defined. Per the rules for identifier referen ces, an identifier will not be treated as a top-level getter invocation unless t he getter $i$ is defined. | 3308 Note that the invocation is always defined. Per the rules for identifier referen ces, an identifier will not be treated as a top-level getter invocation unless t he getter $i$ is defined. |
3212 } | 3309 } |
3213 | 3310 |
3214 The static type of $i$ is the declared return type of $m$. | 3311 The static type of $i$ is the declared return type of $m$. |
(...skipping 381 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
3596 In checked mode, it is a dynamic type error if $o_2$ is not \NULL{} and the inte rface of the class of $o_2$ is not a subtype of the actual type of $e_1.v$. | 3693 In checked mode, it is a dynamic type error if $o_2$ is not \NULL{} and the inte rface of the class of $o_2$ is not a subtype of the actual type of $e_1.v$. |
3597 | 3694 |
3598 Let $T$ be the static type of $e_1$. It is a static type warning if $T$ does not have an accessible instance setter named $v=$ unless either: | 3695 Let $T$ be the static type of $e_1$. It is a static type warning if $T$ does not have an accessible instance setter named $v=$ unless either: |
3599 \begin{itemize} | 3696 \begin{itemize} |
3600 \item $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. Or | 3697 \item $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. Or |
3601 \item $T$ is \code{Type}, $e_1$ is a constant type literal and the class corresp onding to $e_1$ has a static setter named $v=$. | 3698 \item $T$ is \code{Type}, $e_1$ is a constant type literal and the class corresp onding to $e_1$ has a static setter named $v=$. |
3602 \end{itemize} | 3699 \end{itemize} |
3603 | 3700 |
3604 | 3701 |
3605 | 3702 |
3606 It is a static type warning if the static type of $e_2$ may not be assigned to $ T$. The static type of the expression $e_1v$ \code{=} $e_2$ is the static type of $e_2$. | 3703 It is a static type warning if the static type of $e_2$ may not be assigned to t he static type of the formal parameter of the setter $v=$. The static type of the expression $e_1.v$ \code{=} $e_2$ is the static type of $e_2$. |
3607 | 3704 |
3608 Evaluation of an assignment of the form $e_1[e_2]$ \code{=} $e_3$ is equivalent to the evaluation of the expression \code{(a, i, e)\{a.[]=(i, e); \RETURN{} e; \ } ($e_1, e_2, e_3$)}. The static type of the expression $e_1[e_2]$ \code{=} $e_ 3$ is the static type of $e_3$. | 3705 Evaluation of an assignment of the form $e_1[e_2]$ \code{=} $e_3$ is equivalent to the evaluation of the expression \code{(a, i, e)\{a.[]=(i, e); \RETURN{} e; \ } ($e_1, e_2, e_3$)}. The static type of the expression $e_1[e_2]$ \code{=} $e_ 3$ is the static type of $e_3$. |
3609 | 3706 |
3610 % Should we add: It is a dynamic error if $e_1$ evaluates to an constant list o r map. | 3707 % Should we add: It is a dynamic error if $e_1$ evaluates to an constant list o r map. |
3611 | 3708 |
3612 It is as static warning if an assignment of the form $v = e$ occurs inside a top level or static function (be it function, method, getter, or setter) or variabl e initializer and there is neither a local variable declaration with name $v$ n or setter declaration with name $v=$ in the lexical scope enclosing the assignme nt. | 3709 It is a static warning if an assignment of the form $v = e$ occurs inside a top level or static function (be it function, method, getter, or setter) or variable initializer and there is neither a local variable declaration with name $v$ no r setter declaration with name $v=$ in the lexical scope enclosing the assignmen t. |
3613 | 3710 |
3614 It is a compile-time error to invoke any of the setters of class \cd{Object} on a prefix object (\ref{imports}) or on a constant type literal that is immediate ly followed by the token `.'. | 3711 It is a compile-time error to invoke any of the setters of class \cd{Object} on a prefix object (\ref{imports}) or on a constant type literal that is immediate ly followed by the token `.'. |
3615 | 3712 |
3616 | 3713 |
3617 | 3714 |
3618 \subsubsection{Compound Assignment} | 3715 \subsubsection{Compound Assignment} |
3619 \label{compoundAssignment} | 3716 \label{compoundAssignment} |
3620 | 3717 |
3621 A compound assignment of the form $v$ $op\code{=} e$ is equivalent to $v \code{= } v$ $op$ $e$. A compound assignment of the form $C.v$ $op \code{=} e$ is equiva lent to $C.v \code{=} C.v$ $op$ $e$. A compound assignment of the form $e_1.v$ $ op = e_2$ is equivalent to \code{((x) $=>$ x.v = x.v $op$ $e_2$)($e_1$)} where $ x$ is a variable that is not used in $e_2$. A compound assignment of the form $ e_1[e_2]$ $op\code{=} e_3$ is equivalent to | 3718 A compound assignment of the form $v$ $op\code{=} e$ is equivalent to $v \code{= } v$ $op$ $e$. A compound assignment of the form $C.v$ $op \code{=} e$ is equiva lent to $C.v \code{=} C.v$ $op$ $e$. A compound assignment of the form $e_1.v$ $ op = e_2$ is equivalent to \code{((x) $=>$ x.v = x.v $op$ $e_2$)($e_1$)} where $ x$ is a variable that is not used in $e_2$. A compound assignment of the form $ e_1[e_2]$ $op\code{=} e_3$ is equivalent to |
3622 \code{((a, i) $=>$ a[i] = a[i] $op$ $e_3$)($e_1, e_2$)} where $a$ and $i$ are a variables that are not used in $e_3$. | 3719 \code{((a, i) $=>$ a[i] = a[i] $op$ $e_3$)($e_1, e_2$)} where $a$ and $i$ are a variables that are not used in $e_3$. |
(...skipping 21 matching lines...) Expand all Loading... | |
3644 A {\em conditional expression} evaluates one of two expressions based on a boole an condition. | 3741 A {\em conditional expression} evaluates one of two expressions based on a boole an condition. |
3645 | 3742 |
3646 \begin{grammar} | 3743 \begin{grammar} |
3647 {\bf conditionalExpression:} | 3744 {\bf conditionalExpression:} |
3648 logicalOrExpression (`?' expressionWithoutCascade `{\escapegrammar :}' expr essionWithoutCascade)? | 3745 logicalOrExpression (`?' expressionWithoutCascade `{\escapegrammar :}' expr essionWithoutCascade)? |
3649 . % the first branches could top level expressions, it seems, but certainl y NOT the second | 3746 . % the first branches could top level expressions, it seems, but certainl y NOT the second |
3650 \end{grammar} | 3747 \end{grammar} |
3651 | 3748 |
3652 Evaluation of a conditional expression $c$ of the form $e_1 ? e_2 : e_3$ proceed s as follows: | 3749 Evaluation of a conditional expression $c$ of the form $e_1 ? e_2 : e_3$ proceed s as follows: |
3653 | 3750 |
3654 First, $e_1$ is evaluated to an object $o_1$. Then, $o_1$ is subjected to bool ean conversion (\ref{booleanConversion}) producing an object $r$. If $r$ is tru e, then the value of $c$ is the result of evaluating the expression $e_2$. Other wise the value of $c$ is the result of evaluating the expression $e_3$. | 3751 First, $e_1$ is evaluated to an object $o_1$. Then, $o_1$ is subjected to bool ean conversion (\ref{booleanConversion}) producing an object $r$. If $r$ is \TR UE, then the value of $c$ is the result of evaluating the expression $e_2$. Othe rwise the value of $c$ is the result of evaluating the expression $e_3$. |
3655 | 3752 |
3656 If all of the following hold: | 3753 If all of the following hold: |
3657 \begin{itemize} | 3754 \begin{itemize} |
3658 \item $e_1$ shows that a variable $v$ has type $T$. | 3755 \item $e_1$ shows that a variable $v$ has type $T$. |
3659 \item $v$ is not potentially mutated in $e_2$ or within a closure. | 3756 \item $v$ is not potentially mutated in $e_2$ or within a closure. |
3660 \item If the variable $v$ is accessed by a closure in $e_2$ then the variable $v $ is not potentially mutated anywhere in the scope of $v$. | 3757 \item If the variable $v$ is accessed by a closure in $e_2$ then the variable $v $ is not potentially mutated anywhere in the scope of $v$. |
3661 \end{itemize} | 3758 \end{itemize} |
3662 | 3759 |
3663 then the type of $v$ is known to be $T$ in $e_2$. | 3760 then the type of $v$ is known to be $T$ in $e_2$. |
3664 | 3761 |
(...skipping 13 matching lines...) Expand all Loading... | |
3678 | 3775 |
3679 | 3776 |
3680 {\bf logicalAndExpression:} | 3777 {\bf logicalAndExpression:} |
3681 equalityExpression (`\&\&' equalityExpression)* | 3778 equalityExpression (`\&\&' equalityExpression)* |
3682 % bitwiseOrExpression (`\&\&' bitwiseOrExpression)* | 3779 % bitwiseOrExpression (`\&\&' bitwiseOrExpression)* |
3683 . | 3780 . |
3684 \end{grammar} | 3781 \end{grammar} |
3685 | 3782 |
3686 A {\em logical boolean expression} is either an equality expression (\ref{equali ty}), or an invocation of a logical boolean operator on an expression $e_1$ with argument $e_2$. | 3783 A {\em logical boolean expression} is either an equality expression (\ref{equali ty}), or an invocation of a logical boolean operator on an expression $e_1$ with argument $e_2$. |
3687 | 3784 |
3688 Evaluation of a logical boolean expression $b$ of the form $e_1 || e_2$ causes t he evaluation of $e_1$ which is then subjected to boolean conversion, yielding an object $o_1$; if $o_1$ is true, the result of evaluating $b$ is true, otherwi se $e_2$ is evaluated to an object $o_2$, which is then subjected to boolean con version (\ref{booleanConversion}) producing an object $r$, which is the value of $b$. | 3785 Evaluation of a logical boolean expression $b$ of the form $e_1 || e_2$ causes t he evaluation of $e_1$ which is then subjected to boolean conversion, yielding an object $o_1$; if $o_1$ is \TRUE, the result of evaluating $b$ is \TRUE, other wise $e_2$ is evaluated to an object $o_2$, which is then subjected to boolean c onversion (\ref{booleanConversion}) producing an object $r$, which is the value of $b$. |
3689 | 3786 |
3690 Evaluation of a logical boolean expression $b$ of the form $e_1 \&\& e_2$ causes the evaluation of $e_1$ which is then subjected to boolean conversion, yielding an object $o_1$; if $o_1$ is not true, the result of evaluating $b$ is false, otherwise $e_2$ is evaluated to an object $o_2$, which is then subjected to bool ean conversion producing an object $r$, which is the value of $b$. | 3787 Evaluation of a logical boolean expression $b$ of the form $e_1 \&\& e_2$ causes the evaluation of $e_1$ which is then subjected to boolean conversion, yielding an object $o_1$; if $o_1$ is not \TRUE, the result of evaluating $b$ is \FALSE , otherwise $e_2$ is evaluated to an object $o_2$, which is then subjected to bo olean conversion producing an object $r$, which is the value of $b$. |
3691 | 3788 |
3692 A logical boolean expression $b$ of the form $e_1 \&\& e_2$ shows that a variabl e $v$ has type | 3789 A logical boolean expression $b$ of the form $e_1 \&\& e_2$ shows that a variabl e $v$ has type |
3693 $T$ if all of the following conditions hold: | 3790 $T$ if all of the following conditions hold: |
3694 \begin{itemize} | 3791 \begin{itemize} |
3695 \item Either $e_1$ shows that $v$ has type $T$ or $e_2$ shows that $v$ has type $T$. | 3792 \item Either $e_1$ shows that $v$ has type $T$ or $e_2$ shows that $v$ has type $T$. |
3696 \item $v$ is a local variable or formal parameter. | 3793 \item $v$ is a local variable or formal parameter. |
3697 \item The variable $v$ is not mutated in $e_2$ or within a closure. | 3794 \item The variable $v$ is not mutated in $e_2$ or within a closure. |
3698 \end{itemize} | 3795 \end{itemize} |
3699 | 3796 |
3700 Furthermore, if all of the following hold: | 3797 Furthermore, if all of the following hold: |
(...skipping 188 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
3889 | 3986 |
3890 The static type of an multiplicative expression is usually determined by the sig nature given in the declaration of the operator used. However, invocations of th e operators \cd{*}, \cd{\%} and \cd{\~{}/} of class \cd{int} are treated specia lly by the typechecker. The static type of an expression $e_1 * e_2$ where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}, a nd \cd{double} if the static type of $e_2$ is \cd{double}. The static type of an expression $e_1 \% e_2$ where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}, and \cd{double} if the static type of $e_2$ i s \cd{double}. The static type of an expression \cd{$e_1$ \~{}/ $e_2$} where $e _1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int} . | 3987 The static type of an multiplicative expression is usually determined by the sig nature given in the declaration of the operator used. However, invocations of th e operators \cd{*}, \cd{\%} and \cd{\~{}/} of class \cd{int} are treated specia lly by the typechecker. The static type of an expression $e_1 * e_2$ where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}, a nd \cd{double} if the static type of $e_2$ is \cd{double}. The static type of an expression $e_1 \% e_2$ where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}, and \cd{double} if the static type of $e_2$ i s \cd{double}. The static type of an expression \cd{$e_1$ \~{}/ $e_2$} where $e _1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int} . |
3891 | 3988 |
3892 \subsection{ Unary Expressions} | 3989 \subsection{ Unary Expressions} |
3893 \label{unaryExpressions} | 3990 \label{unaryExpressions} |
3894 | 3991 |
3895 Unary expressions invoke unary operators on objects. | 3992 Unary expressions invoke unary operators on objects. |
3896 | 3993 |
3897 \begin{grammar} | 3994 \begin{grammar} |
3898 {\bf unaryExpression:}prefixOperator unaryExpression; | 3995 {\bf unaryExpression:}prefixOperator unaryExpression; |
3996 awaitExpression; | |
3899 postfixExpression; | 3997 postfixExpression; |
3900 (minusOperator $|$ tildeOperator) \SUPER{}; | 3998 (minusOperator $|$ tildeOperator) \SUPER{}; |
3901 incrementOperator assignableExpression | 3999 incrementOperator assignableExpression |
3902 . | 4000 . |
3903 | 4001 |
3904 {\bf prefixOperator:}minusOperator; | 4002 {\bf prefixOperator:}minusOperator; |
3905 negationOperator; | 4003 negationOperator; |
3906 tildeOperator | 4004 tildeOperator |
3907 . | 4005 . |
3908 | 4006 |
3909 | 4007 |
3910 {\bf minusOperator:}`-'; . | 4008 {\bf minusOperator:}`-'; . |
3911 | 4009 |
3912 | 4010 |
3913 {\bf negationOperator:}`!' ; | 4011 {\bf negationOperator:}`!' ; |
3914 . | 4012 . |
3915 | 4013 |
3916 {\bf tildeOperator:} `\~{}' | 4014 {\bf tildeOperator:} `\~{}' |
3917 . | 4015 . |
3918 | 4016 |
3919 | 4017 |
3920 \end{grammar} | 4018 \end{grammar} |
3921 | 4019 |
3922 A {\em unary expression} is either a postfix expression (\ref{postfixExpression s}), an invocation of a prefix operator on an expression or an invocation of a u nary operator on either \SUPER{} or an expression $e$. | 4020 A {\em unary expression} is either a postfix expression (\ref{postfixExpression s}), an await expression (\ref{awaitExpressions}) or an invocation of a prefix o perator on an expression or an invocation of a unary operator on either \SUPER{} or an expression $e$. |
3923 | 4021 |
3924 The expression $!e$ is equivalent to the expression $e? \FALSE{} :\TRUE{}$. | 4022 The expression $!e$ is equivalent to the expression $e?$ $ \FALSE{} :\TRUE{}$. |
3925 | 4023 |
3926 Evaluation of an expression of the form \code{++$e$} is equivalent to \code{$e$ += 1}. Evaluation of an expression of the form \code{-{}-$e$} is equivalent to \code{$e$ -= 1}. | 4024 Evaluation of an expression of the form \code{++$e$} is equivalent to \code{$e$ += 1}. Evaluation of an expression of the form \code{-{}-$e$} is equivalent to \code{$e$ -= 1}. |
3927 | 4025 |
3928 %The expression $-e$ is equivalent to the method invocation \code{$e$.-()}. The expression \code{-\SUPER{}} is equivalent to the method invocation \code{\SUPE R{}.-()}. | 4026 %The expression $-e$ is equivalent to the method invocation \code{$e$.-()}. The expression \code{-\SUPER{}} is equivalent to the method invocation \code{\SUPE R{}.-()}. |
3929 | 4027 |
3930 An expression of the form \code{$op$ $e$} is equivalent to the method invocation \code{$e.op()$}. An expression of the form \code{$op$ \SUPER{}} is equivalent t o the method invocation \code{\SUPER{}.$op()$}. | 4028 An expression of the form \code{$op$ $e$} is equivalent to the method invocation \code{$e.op()$}. An expression of the form \code{$op$ \SUPER{}} is equivalent t o the method invocation (\ref{superInvocation}) \code{\SUPER{}.$op()$}. |
4029 | |
4030 \subsection{ Await Expressions} | |
4031 \label{awaitExpressions} | |
4032 | |
4033 An {\em await expression} allows code to yield control until an asynchronous ope ration (\ref{functions}) completes. | |
4034 | |
4035 \begin{grammar} | |
4036 {\bf awaitExpression:} | |
4037 \AWAIT{} unaryExpression | |
4038 \end{grammar} | |
4039 | |
4040 Evaluation of an await expression $a$ of the form \AWAIT{} $e$ proceeds as follo ws: | |
4041 First, the expression $e$ is evaluated. Next: | |
4042 | |
4043 If $e$ evaluates to an instance of \code{Future}, $f$, then execution of the fun ction $m$ immediately enclosing $a$ is suspended until after $f$ completes. The stream associated with the innermost enclosing asynchronous for loop (\ref{async hronousFor-in}), if any, is paused. At some time after $f$ is completed, control returns to the current invocation. The stream associated with the innermost enc losing asynchronous for loop (\ref{asynchronousFor-in}), if any, is resumed. If $f$ has completed with an exception $x$, $a$ raises $x$. If $f$ completes with a value $v$, $a$ evaluates to $v$. | |
4044 | |
4045 Otherwise, the value of $a$ is the value of $e$. If evaluation of $e$ raises an exception $x$, $a$ raises $x$. | |
4046 | |
4047 \commentary{ | |
4048 It is a compile-time error if the function immediately enclosing $a$ is not declared asynchronous. However, this error is simply a syntax error, because in the context of a normal function, \AWAIT{} has no special meaning. | |
4049 } | |
4050 | |
4051 \rationale{ | |
4052 An await expression has no meaning in a synchronous function. If such a function were to suspend waiting for a future, it would no longer be synchronous. | |
4053 } | |
4054 | |
4055 \commentary{ | |
4056 It is not a static warning if the type of $e$ is not a subtype of \code{Future}. Tools may choose to give a hint in such cases. | |
4057 } | |
4058 | |
4059 Let $flatten(T) = flatten(S)$ if $T = Future<S>$, and $T$ otherwise. The static type of $a$ is $flatten(T)$ where $T$ is the static type of $e$. | |
4060 | |
4061 \rationale{ | |
4062 We collapse multiple layers of futures into one. If $e$ evaluates to a future $f $, the future will not invoke its \code{then()} callback until f completes to a non-future value, and so the result of an await is never a future, and the resul t of an async function will never have type \code{Future$<X>$} where $X$ itself is an invocation of \code{Future}. | |
4063 } | |
4064 | |
3931 | 4065 |
3932 | 4066 |
3933 | 4067 |
3934 \subsection{ Postfix Expressions} | 4068 \subsection{ Postfix Expressions} |
3935 \label{postfixExpressions} | 4069 \label{postfixExpressions} |
3936 | 4070 |
3937 Postfix expressions invoke the postfix operators on objects. | 4071 Postfix expressions invoke the postfix operators on objects. |
3938 | 4072 |
3939 \begin{grammar} | 4073 \begin{grammar} |
3940 {\bf postfixExpression:}assignableExpression postfixOperator; | 4074 {\bf postfixExpression:}assignableExpression postfixOperator; |
(...skipping 149 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
4090 DIGIT | 4224 DIGIT |
4091 . | 4225 . |
4092 | 4226 |
4093 | 4227 |
4094 | 4228 |
4095 {\bf qualified:} | 4229 {\bf qualified:} |
4096 identifier (`{\escapegrammar .}' identifier)? | 4230 identifier (`{\escapegrammar .}' identifier)? |
4097 . | 4231 . |
4098 \end{grammar} | 4232 \end{grammar} |
4099 | 4233 |
4100 A built-in identifier is one of the identifiers produced by the production {\em BUILT\_IN\_IDENTIFIER}. It is a compile-time error if a built-in identifier is u sed as the declared name of a prefix, class, type parameter or type alias. It is a compile-time error to use a built-in identifier other than \DYNAMIC{} as a ty pe annotation. | 4234 A built-in identifier is one of the identifiers produced by the production {\em BUILT\_IN\_IDENTIFIER}. It is a compile-time error if a built-in identifier is u sed as the declared name of a prefix, class, type parameter or type alias. It is a compile-time error to use a built-in identifier other than \DYNAMIC{} as a ty pe annotation or type parameter. |
4101 | 4235 |
4102 \rationale{ | 4236 \rationale{ |
4103 Built-in identifiers are identifiers that are used as keywords in Dart, but are not reserved words in Javascript. To minimize incompatibilities when porting Jav ascript code to Dart, we do not make these into reserved words. A built-in ident ifier may not be used to name a class or type. In other words, they are treated as reserved words when used as types. This eliminates many confusing situations without causing compatibility problems. After all, a Javascript program has no type declarations or annotations so no clash can occur. Furthermore, types shou ld begin with an uppercase letter (see the appendix) and so no clash should occu r in any Dart user program anyway. | 4237 Built-in identifiers are identifiers that are used as keywords in Dart, but are not reserved words in Javascript. To minimize incompatibilities when porting Jav ascript code to Dart, we do not make these into reserved words. A built-in ident ifier may not be used to name a class or type. In other words, they are treated as reserved words when used as types. This eliminates many confusing situations without causing compatibility problems. After all, a Javascript program has no type declarations or annotations so no clash can occur. Furthermore, types shou ld begin with an uppercase letter (see the appendix) and so no clash should occu r in any Dart user program anyway. |
4104 } | 4238 } |
4105 | 4239 |
4240 It is a compile-time error if any of the identifiers \ASYNC, \AWAIT{} or \YIELD{ } is used as an identifier in a function body marked with either \ASYNC{}, \ASYN C* or \SYNC*. | |
4241 | |
4242 \rationale{ | |
4243 For compatibility reasons, new constructs cannot rely upon new reserved words o r even built-in identifiers. However, the constructs above are only usable in co ntexts that require special markers introduced concurrently with these construct s, so no old code could use them. Hence the restriction, which treats these name s as reserved words in a limited context. | |
4244 } | |
4245 | |
4106 Evaluation of an identifier expression $e$ of the form $id$ proceeds as follows: | 4246 Evaluation of an identifier expression $e$ of the form $id$ proceeds as follows: |
4107 | 4247 |
4108 | 4248 |
4109 Let $d$ be the innermost declaration in the enclosing lexical scope whose name i s $id$ or $id=$. If no such declaration exists in the lexical scope, let $d$ be the declaration of the inherited member named $id$ if it exists. | 4249 Let $d$ be the innermost declaration in the enclosing lexical scope whose name i s $id$ or $id=$. If no such declaration exists in the lexical scope, let $d$ be the declaration of the inherited member named $id$ if it exists. |
4110 %If no such member exists, let $d$ be the declaration of the static member name $id$ declared in a superclass of the current class, if it exists. | 4250 %If no such member exists, let $d$ be the declaration of the static member name $id$ declared in a superclass of the current class, if it exists. |
4111 | 4251 |
4112 \begin{itemize} | 4252 \begin{itemize} |
4113 \item if $d$ is a prefix $p$, a compile-time error occurs unless the token immed iately following $d$ is \code{'.'}. | 4253 \item if $d$ is a prefix $p$, a compile-time error occurs unless the token immed iately following $d$ is \code{'.'}. |
4114 \item If $d$ is a class or type alias $T$, the value of $e$ is an instance of c lass \code{Type} (or a subclass thereof) reifying $T$. | 4254 \item If $d$ is a class or type alias $T$, the value of $e$ is an instance of c lass \code{Type} (or a subclass thereof) reifying $T$. |
4115 \item If $d$ is a type parameter $T$, then the value of $e$ is the value of the actual type argument corresponding to $T$ that was passed to the generative con structor that created the current binding of \THIS{}. If, however, $e$ occurs in side a static member, a compile-time error occurs. | 4255 \item If $d$ is a type parameter $T$, then the value of $e$ is the value of the actual type argument corresponding to $T$ that was passed to the generative con structor that created the current binding of \THIS{}. If, however, $e$ occurs in side a static member, a compile-time error occurs. |
(...skipping 47 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
4163 . | 4303 . |
4164 | 4304 |
4165 | 4305 |
4166 {\bf isOperator:} | 4306 {\bf isOperator:} |
4167 \IS{} `!'? | 4307 \IS{} `!'? |
4168 . | 4308 . |
4169 \end{grammar} | 4309 \end{grammar} |
4170 | 4310 |
4171 Evaluation of the is-expression \code{$e$ \IS{} $T$} proceeds as follows: | 4311 Evaluation of the is-expression \code{$e$ \IS{} $T$} proceeds as follows: |
4172 | 4312 |
4173 The expression $e$ is evaluated to a value $v$. Then, if $T$ is a malformed or d eferred type (\ref{staticTypes}), a dynamic error occurs. Otherwise, if the inte rface of the class of $v$ is a subtype of $T$, the is-expression evaluates to tr ue. Otherwise it evaluates to false. | 4313 The expression $e$ is evaluated to a value $v$. Then, if $T$ is a malformed or d eferred type (\ref{staticTypes}), a dynamic error occurs. Otherwise, if the inte rface of the class of $v$ is a subtype of $T$, the is-expression evaluates to \T RUE. Otherwise it evaluates to \FALSE. |
4174 | 4314 |
4175 \commentary{It follows that \code{$e$ \IS{} Object} is always true. This makes s ense in a language where everything is an object. | 4315 \commentary{It follows that \code{$e$ \IS{} Object} is always true. This makes s ense in a language where everything is an object. |
4176 | 4316 |
4177 Also note that \code{\NULL{} \IS{} $T$} is false unless $T = \code{Object}$, $T = \code{\DYNAMIC{}}$ or $T = \code{Null}$. The former two are useless, as is an ything of the form \code{$e$ \IS{} Object} or \code{$e$ \IS{} \DYNAMIC{}}. User s should test for a null value directly rather than via type tests. | 4317 Also note that \code{\NULL{} \IS{} $T$} is false unless $T = \code{Object}$, $T = \code{\DYNAMIC{}}$ or $T = \code{Null}$. The former two are useless, as is an ything of the form \code{$e$ \IS{} Object} or \code{$e$ \IS{} \DYNAMIC{}}. User s should test for a null value directly rather than via type tests. |
4178 } | 4318 } |
4179 | 4319 |
4180 The is-expression \code{$e$ \IS{}! $T$} is equivalent to \code{!($e$ \IS{} $T$)} . | 4320 The is-expression \code{$e$ \IS{}! $T$} is equivalent to \code{!($e$ \IS{} $T$)} . |
4181 | 4321 |
4182 % Add flow dependent types | 4322 % Add flow dependent types |
4183 | 4323 |
(...skipping 55 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
4239 forStatement; | 4379 forStatement; |
4240 whileStatement; | 4380 whileStatement; |
4241 doStatement; | 4381 doStatement; |
4242 switchStatement; | 4382 switchStatement; |
4243 ifStatement; | 4383 ifStatement; |
4244 rethrowStatement; | 4384 rethrowStatement; |
4245 tryStatement; | 4385 tryStatement; |
4246 breakStatement; | 4386 breakStatement; |
4247 continueStatement; | 4387 continueStatement; |
4248 returnStatement; | 4388 returnStatement; |
4389 yieldStatement; | |
4390 yieldEachStatement; | |
4249 expressionStatement; | 4391 expressionStatement; |
4250 assertStatement; | 4392 assertStatement; |
4251 localFunctionDeclaration | 4393 localFunctionDeclaration |
4252 . | 4394 . |
4253 \end{grammar} | 4395 \end{grammar} |
4254 | 4396 |
4255 \subsection{Blocks} | 4397 \subsection{Blocks} |
4256 \label{blocks} | 4398 \label{blocks} |
4257 | 4399 |
4258 A {\em block statement} supports sequencing of code. | 4400 A {\em block statement} supports sequencing of code. |
(...skipping 170 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
4429 | 4571 |
4430 | 4572 |
4431 | 4573 |
4432 \subsection{For} | 4574 \subsection{For} |
4433 \label{for} | 4575 \label{for} |
4434 | 4576 |
4435 The {\em for statement} supports iteration. | 4577 The {\em for statement} supports iteration. |
4436 | 4578 |
4437 \begin{grammar} | 4579 \begin{grammar} |
4438 {\bf forStatement:} | 4580 {\bf forStatement:} |
4439 \FOR{} `(' forLoopParts `)' statement | 4581 \AWAIT? \FOR{} `(' forLoopParts `)' statement |
4440 . | 4582 . |
4441 | 4583 |
4442 {\bf forLoopParts:}forInitializerStatement expression? `{\escapegrammar ;}' expr essionList?; | 4584 {\bf forLoopParts:}forInitializerStatement expression? `{\escapegrammar ;}' expr essionList?; |
4443 declaredIdentifier \IN{} expression; | 4585 declaredIdentifier \IN{} expression; |
4444 identifier \IN{} expression | 4586 identifier \IN{} expression |
4445 . | 4587 . |
4446 | 4588 |
4447 {\bf forInitializerStatement:}localVariableDeclaration `{\escapegrammar ;}'; | 4589 {\bf forInitializerStatement:}localVariableDeclaration `{\escapegrammar ;}'; |
4448 expression? `{\escapegrammar ;}' | 4590 expression? `{\escapegrammar ;}' |
4449 . | 4591 . |
4450 \end{grammar} | 4592 \end{grammar} |
4451 | 4593 |
4452 The for statement has two forms - the traditional for loop and the for-in state ment. | 4594 The for statement has three forms - the traditional for loop and two forms of t he for-in statement - synchronous and asynchronous. |
4453 | 4595 |
4454 \subsubsection{For Loop} | 4596 \subsubsection{For Loop} |
4455 \label{forLoop} | 4597 \label{forLoop} |
4456 | 4598 |
4457 | 4599 |
4458 Execution of a for statement of the form \code{ \FOR{} (\VAR{} $v = e_0$ ; $c$ ; $e$) $s$} proceeds as follows: | 4600 Execution of a for statement of the form \code{ \FOR{} (\VAR{} $v = e_0$ ; $c$ ; $e$) $s$} proceeds as follows: |
4459 | 4601 |
4460 If $c$ is empty then let $c^\prime$ be \TRUE{} otherwise let $c^\prime$ be $c$. | 4602 If $c$ is empty then let $c^\prime$ be \TRUE{} otherwise let $c^\prime$ be $c$. |
4461 | 4603 |
4462 First the variable declaration statement \VAR{} $v = e_0$ is executed. Then: | 4604 First the variable declaration statement \VAR{} $v = e_0$ is executed. Then: |
(...skipping 46 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
4509 $finalConstVarOrType?$ id = n0.current; | 4651 $finalConstVarOrType?$ id = n0.current; |
4510 $s$ | 4652 $s$ |
4511 \} | 4653 \} |
4512 \end{dartCode} | 4654 \end{dartCode} |
4513 where \code{n0} is an identifier that does not occur anywhere in the program. | 4655 where \code{n0} is an identifier that does not occur anywhere in the program. |
4514 | 4656 |
4515 \commentary{ | 4657 \commentary{ |
4516 Note that in fact, using a \CONST{} variable would give rise to a compile time error since \cd{n0.current} is not a constant expression. | 4658 Note that in fact, using a \CONST{} variable would give rise to a compile time error since \cd{n0.current} is not a constant expression. |
4517 } | 4659 } |
4518 | 4660 |
4661 \subsubsection{Asynchronous For-in} | |
4662 \label{asynchronousFor-in} | |
4663 | |
4664 A for-in statement may be asynchronous. The asynchronous form is designed to ite rate over streams. An asynchronous for loop is distinguished by the keyword \AWA IT{} immediately preceding the keyword \FOR. | |
4665 | |
4666 Execution of a for-in statement of the form \code{\AWAIT{} \FOR{} (finalConstVa rOrType? id \IN{} $e$) $s$} proceeds as follows: | |
4667 | |
4668 The expression $e$ is evaluated to an object $o$. It is a dynamic error if $o$ i s not an instance of a class that implements \code{Stream}. Otherwise, the expre ssion \code{\AWAIT{} $v_f$} (\ref{awaitExpressions}) is evaluated, where $v_f$ is a fresh variable whose value is a fresh instance (\ref{generativeConstructors }) $f$ implementing the built-in class \code{Future}. | |
4669 | |
4670 The stream $o$ is listened to, and on each data event in $o$ the statement $s$ is executed with \code{id} bound to the value of the current element of the stre am. If $s$ raises an exception, or if $o$ raises an exception, then $f$ is compl eted with that exception. Otherwise, when all events in the stream $o$ have been processed, $f$ is completed with \NULL{} (\ref{null}). | |
4671 | |
4672 Let $u$ be the stream associated with the immediately enclosing asynchronous for loop or generator function (\ref{functions}), if any. If another event $e_u$ of $u$ occurs before execution of $s$ is complete, handling of $e_u$ must wait unt il $s$ is complete. | |
4673 | |
4674 \rationale{ | |
4675 The future $f$ and the corresponding \AWAIT{} expression ensure that execution s uspends as an asynchronous for loop begins and resumes after the \FOR{} statemen t when it ends. They also ensure that the stream of any enclosing asynchronous \ FOR{} loop is paused for the duration of this loop. | |
4676 } | |
4677 | |
4678 It is a compile-time error if an asynchronous for-in statement appears inside a synchronous function (\ref{functions}). It is a compile-time error if a traditio nal for loop (\ref{forLoop}) is prefixed by the \AWAIT{} keyword. | |
4679 | |
4680 \rationale{An asynchronous loop would make no sense within a synchronous functio n, for the same reasons that an await expression makes no sense in a synchronous function.} | |
4681 | |
4682 | |
4519 \subsection{While} | 4683 \subsection{While} |
4520 \label{while} | 4684 \label{while} |
4521 | 4685 |
4522 The while statement supports conditional iteration, where the condition is evalu ated prior to the loop. | 4686 The while statement supports conditional iteration, where the condition is evalu ated prior to the loop. |
4523 | 4687 |
4524 \begin{grammar} | 4688 \begin{grammar} |
4525 {\bf whileStatement:} | 4689 {\bf whileStatement:} |
4526 \WHILE{} `(' expression `)' statement % could do top level here, and in f or | 4690 \WHILE{} `(' expression `)' statement % could do top level here, and in f or |
4527 . | 4691 . |
4528 \end{grammar} | 4692 \end{grammar} |
(...skipping 152 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
4681 If execution reaches the point after $s_h$ then a runtime error occurs, unless $h = n$. | 4845 If execution reaches the point after $s_h$ then a runtime error occurs, unless $h = n$. |
4682 | 4846 |
4683 | 4847 |
4684 \commentary{ | 4848 \commentary{ |
4685 In other words, there is no implicit fall-through between cases. The last case i n a switch (default or otherwise) can `fall-through' to the end of the statement . | 4849 In other words, there is no implicit fall-through between cases. The last case i n a switch (default or otherwise) can `fall-through' to the end of the statement . |
4686 } | 4850 } |
4687 | 4851 |
4688 It is a static warning if the type of $e$ may not be assigned to the type of $e_ k$. It is a static warning if the last statement of the statement sequence $s_k$ is not a \BREAK{}, \CONTINUE{}, \RETURN{} or \THROW{} statement. | 4852 It is a static warning if the type of $e$ may not be assigned to the type of $e_ k$. It is a static warning if the last statement of the statement sequence $s_k$ is not a \BREAK{}, \CONTINUE{}, \RETURN{} or \THROW{} statement. |
4689 | 4853 |
4690 \rationale{ | 4854 \rationale{ |
4691 The behavior of switch cases intentionally differs from the C tradition. Implic it fall through is a known cause of programming errors and therefore disallowed. Why not simply break the flow implicitly at the end of every case, rather than requiring explicit code to do so? This would indeed be cleaner. It would also be cleaner to insist that each case have a single (possibly compound) statement . We have chosen not to do so in order to facilitate porting of switch statemen ts from other languages. Implicitly breaking the control flow at the end of a c ase would silently alter the meaning of ported code that relied on fall-through, potentially forcing the programmer to deal with subtle bugs. Our design ensures that the difference is immediately brought to the coder`s attention. The progr ammer will be notified at compile-time if they forget to end a case with a state ment that terminates the straight-line control flow. We could make this warning a compile-time error, but refrain from doing so because do not wish to force the programmer to deal with this issue immediately while porting code. If develope rs ignore the warning and run their code, a run time error will prevent the prog ram from misbehaving in hard-to-debug ways (at least with respect to this issue) . | 4855 The behavior of switch cases intentionally differs from the C tradition. Implic it fall through is a known cause of programming errors and therefore disallowed. Why not simply break the flow implicitly at the end of every case, rather than requiring explicit code to do so? This would indeed be cleaner. It would also be cleaner to insist that each case have a single (possibly compound) statement . We have chosen not to do so in order to facilitate porting of switch statemen ts from other languages. Implicitly breaking the control flow at the end of a c ase would silently alter the meaning of ported code that relied on fall-through, potentially forcing the programmer to deal with subtle bugs. Our design ensures that the difference is immediately brought to the coder's attention. The progr ammer will be notified at compile-time if they forget to end a case with a state ment that terminates the straight-line control flow. We could make this warning a compile-time error, but refrain from doing so because do not wish to force the programmer to deal with this issue immediately while porting code. If develope rs ignore the warning and run their code, a run time error will prevent the prog ram from misbehaving in hard-to-debug ways (at least with respect to this issue) . |
4692 | 4856 |
4693 The sophistication of the analysis of fall-through is another issue. For now, we have opted for a very straightforward syntactic requirement. There are obviousl y situations where code does not fall through, and yet does not conform to these simple rules, e.g.: | 4857 The sophistication of the analysis of fall-through is another issue. For now, we have opted for a very straightforward syntactic requirement. There are obviousl y situations where code does not fall through, and yet does not conform to these simple rules, e.g.: |
4694 } | 4858 } |
4695 | 4859 |
4696 \begin{dartCode} | 4860 \begin{dartCode} |
4697 \SWITCH{} (x) \{ | 4861 \SWITCH{} (x) \{ |
4698 \CASE{} 1: \TRY{} \{ $\ldots$ \RETURN{};\} \FINALLY{} \{ $\ldots$ \RETURN{};\} | 4862 \CASE{} 1: \TRY{} \{ $\ldots$ \RETURN{};\} \FINALLY{} \{ $\ldots$ \RETURN{};\} |
4699 \} | 4863 \} |
4700 \end{dartCode} | 4864 \end{dartCode} |
4701 | 4865 |
(...skipping 14 matching lines...) Expand all Loading... | |
4716 | 4880 |
4717 | 4881 |
4718 \subsection{ Rethrow} | 4882 \subsection{ Rethrow} |
4719 \label{rethrow} | 4883 \label{rethrow} |
4720 | 4884 |
4721 | 4885 |
4722 The {\em rethrow statement} is used to re-raise an exception. | 4886 The {\em rethrow statement} is used to re-raise an exception. |
4723 | 4887 |
4724 \begin{grammar} | 4888 \begin{grammar} |
4725 {\bf rethrowStatement:} | 4889 {\bf rethrowStatement:} |
4726 \RETHROW{} | 4890 \RETHROW{} `{\escapegrammar ;}' |
4727 . | 4891 . |
4728 \end{grammar} | 4892 \end{grammar} |
4729 | 4893 |
4730 Execution of a \code{\RETHROW{}} statement proceeds as follows: | 4894 Execution of a \code{\RETHROW{}} statement proceeds as follows: |
4731 Control is transferred to the nearest innermost enclosing exception handler (\re f{try}). | |
4732 | 4895 |
4733 \commentary{No change is made to the current exception.} | 4896 Let $f$ be the immediately enclosing function, and let \code{\ON{} $T$ \CATCH{} ($p_1$, $p_2$)} be the immediately enclosing catch clause (\ref{try}). |
4734 | 4897 |
4735 It is a compile-time error if a \code{\RETHROW{}} statement is not enclosed wit hin an on-catch clause. | 4898 \rationale{ |
4899 A \RETHROW{} statement always appears inside a \CATCH{} clause, and any \CATCH{} clause is semantically equivalent to some \CATCH{} clause of the form \code{\ON {} $T$ \CATCH{} (p1, p2)}. So we can assume that the \RETHROW{} is enclosed in a \CATCH{} clause of that form. | |
4900 } | |
4736 | 4901 |
4737 %The static type of a rethrow expression is $\bot$. | 4902 The current exception (\ref{throw}) is set to $p_1$, the current return value (\ ref{return}) becomes undefined, and the active stack trace (\ref{try}) is set to $p_2$. |
4903 | |
4904 If $f$ is marked \ASYNC{} or \ASYNC* (\ref{functions}) and there is a dynamicall y enclosing exception handler (\ref{try}) $h$ introduced by the current activati on, control is transferred to $h$, otherwise $f$ terminates. | |
4905 | |
4906 \rationale{ | |
4907 In the case of an asynchronous function, the dynamically enclosing exception han dler is only relevant within the function. If an exception is not caught within the function, the exception value is channelled through a future or stream rathe r than propagating via exception handlers. | |
4908 } | |
4909 | |
4910 Otherwise, control is transferred to the innermost enclosing exception handler. | |
4911 | |
4912 \commentary{The change in control may result in multiple functions terminating i f these functions do not catch the exception via a \CATCH{} or \FINALLY{} clause , both of which introduce a dynamically enclosing exception handler.} | |
4913 | |
4914 It is a compile-time error if a \code{\RETHROW{}} statement is not enclosed wit hin an \ON-\CATCH{} clause. | |
4738 | 4915 |
4739 | 4916 |
4740 | 4917 |
4741 \subsection{ Try} | 4918 \subsection{ Try} |
4742 \label{try} | 4919 \label{try} |
4743 | 4920 |
4744 The try statement supports the definition of exception handling code in a struct ured way. | 4921 The try statement supports the definition of exception handling code in a struct ured way. |
4745 | 4922 |
4746 \begin{grammar} | 4923 \begin{grammar} |
4747 {\bf tryStatement:} | 4924 {\bf tryStatement:} |
(...skipping 24 matching lines...) Expand all Loading... | |
4772 \rationale{ | 4949 \rationale{ |
4773 The syntax is designed to be upward compatible with existing Javascript programs . The \ON{} clause can be omitted, leaving what looks like a Javascript catch cl ause. | 4950 The syntax is designed to be upward compatible with existing Javascript programs . The \ON{} clause can be omitted, leaving what looks like a Javascript catch cl ause. |
4774 } | 4951 } |
4775 | 4952 |
4776 An \ON{}-\CATCH{} clause of the form \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$ } {\em matches} an object $o$ if the type of $o$ is a subtype of $T$. If $T$ is a malformed or deferred type (\ref{staticTypes}), then performing a match ca uses a run time error. | 4953 An \ON{}-\CATCH{} clause of the form \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$ } {\em matches} an object $o$ if the type of $o$ is a subtype of $T$. If $T$ is a malformed or deferred type (\ref{staticTypes}), then performing a match ca uses a run time error. |
4777 | 4954 |
4778 \commentary { | 4955 \commentary { |
4779 It is of course a static warning if $T$ is a deferred or malformed type. | 4956 It is of course a static warning if $T$ is a deferred or malformed type. |
4780 } | 4957 } |
4781 | 4958 |
4782 An \ON{}-\CATCH{} clause of the form \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$ } introduces a new scope $CS$ in which local variables specified by $p_1$ and $p _2$ are defined. The statement $s$ is enclosed within $CS$. | 4959 An \ON{}-\CATCH{} clause of the form \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$ } introduces a new scope $CS$ in which final local variables specified by $p_1$ and $p_2$ are defined. The statement $s$ is enclosed within $CS$. The static typ e of $p_1$ is $T$ and the static type of $p_2$ is \code{StackTrace}. |
4783 | 4960 |
4784 | 4961 |
4785 An \ON{}-\CATCH{} clause of the form \code{\ON{} $T$ \CATCH{} ($p_1$) $s$} is e quivalent to an \ON{}-\CATCH{} clause \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$ } where $p_2$ is an identifier that does not occur anywhere else in the program. | 4962 An \ON{}-\CATCH{} clause of the form \code{\ON{} $T$ \CATCH{} ($p_1$) $s$} is e quivalent to an \ON{}-\CATCH{} clause \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$ } where $p_2$ is an identifier that does not occur anywhere else in the program. |
4786 | 4963 |
4787 | 4964 |
4788 An \ON{}-\CATCH{} clause of the form \code{\CATCH{} ($p$) $s$} is equivalent to an \ON{}-\CATCH{} clause \code{\ON{} \DYNAMIC{} \CATCH{} ($p$) $s$}. An \ON{}- \CATCH{} clause of the form \code{\CATCH{} ($p_1, p_2$) $s$} is equivalent to a n \ON{}-\CATCH{} clause \code{\ON{} \DYNAMIC{} \CATCH{} ($p_1, p_2$) $s$} | 4965 An \ON{}-\CATCH{} clause of the form \code{\CATCH{} ($p$) $s$} is equivalent to an \ON{}-\CATCH{} clause \code{\ON{} \DYNAMIC{} \CATCH{} ($p$) $s$}. An \ON{}- \CATCH{} clause of the form \code{\CATCH{} ($p_1, p_2$) $s$} is equivalent to a n \ON{}-\CATCH{} clause \code{\ON{} \DYNAMIC{} \CATCH{} ($p_1, p_2$) $s$}. |
4789 | 4966 |
4790 | 4967 |
4791 %If an explicit type is associated with of $p_2$, it is a static warning if that type is not \code{Object} or \DYNAMIC{}. | 4968 %If an explicit type is associated with of $p_2$, it is a static warning if that type is not \code{Object} or \DYNAMIC{}. |
4792 | 4969 |
4793 The {\em active stack trace} is an object whose \code{toString()} method produce s a string that is a record of exactly those function activations within the cur rent isolate that had not completed execution at the point where the current exc eption was thrown. | 4970 The {\em active stack trace} is an object whose \code{toString()} method produce s a string that is a record of exactly those function activations within the cur rent isolate that had not completed execution at the point where the current exc eption (\ref{throw}) was thrown. |
4794 %\begin{enumerate} | 4971 %\begin{enumerate} |
4795 %\item Started execution after the currently executing function. | 4972 %\item Started execution after the currently executing function. |
4796 %\item Had not completed execution at the point where the exception caught by th e currently executing \ON{}-\CATCH{} clause was initially thrown. | 4973 %\item Had not completed execution at the point where the exception caught by th e currently executing \ON{}-\CATCH{} clause was initially thrown. |
4797 %\commentary{The active stack trace contains the frames between the exception ha ndling code and the original point when an exception is thrown, not where it was rethrown.} | 4974 %\commentary{The active stack trace contains the frames between the exception ha ndling code and the original point when an exception is thrown, not where it was rethrown.} |
4798 %\end{enumerate} | 4975 %\end{enumerate} |
4799 | 4976 |
4800 \commentary{ | 4977 \commentary{ |
4801 This implies that no synthetic function activations may be added to the trace, n or may any source level activations be omitted. | 4978 This implies that no synthetic function activations may be added to the trace, n or may any source level activations be omitted. |
4802 This means, for example, that any inlining of functions done as an optimization must not be visible in the trace. Similarly, any synthetic routines used by the implementation must not appear in the trace. | 4979 This means, for example, that any inlining of functions done as an optimization must not be visible in the trace. Similarly, any synthetic routines used by the implementation must not appear in the trace. |
4803 | 4980 |
4804 Nothing is said about how any native function calls may be represented in the tr ace. | 4981 Nothing is said about how any native function calls may be represented in the tr ace. |
4805 } | 4982 } |
4806 | 4983 |
4807 \commentary{ | 4984 \commentary{ |
4808 Note that we say nothing about the identity of the stack trace, or what notion o f equality is defined for stack traces. | 4985 Note that we say nothing about the identity of the stack trace, or what notion o f equality is defined for stack traces. |
4809 } | 4986 } |
4810 | 4987 |
4811 % Sadly, the info below cannot be computed efficiently. It would need to be comp uted at the throw point, since at latte points it might be destroyed. Native cod e in calling frames executes relative to the stack pointer, which therefore need s to be reset as each frame is unwound. This means that the | 4988 % Sadly, the info below cannot be computed efficiently. It would need to be comp uted at the throw point, since at latte points it might be destroyed. Native cod e in calling frames executes relative to the stack pointer, which therefore need s to be reset as each frame is unwound. This means that the |
4812 % OS kernel can dispose of this stack memory - it is not reliably preserved. And such code must execute if only to test if the exception should be caught or sen t onward. | 4989 % OS kernel can dispose of this stack memory - it is not reliably preserved. And such code must execute if only to test if the exception should be caught or sen t onward. |
4813 | 4990 |
4814 % For each such function activation, the active stack trace includes the name of the function, the bindings of all its formal parameters, local variables and \T HIS{}, and the position at which the function was executing. | 4991 % For each such function activation, the active stack trace includes the name of the function, the bindings of all its formal parameters, local variables and \T HIS{}, and the position at which the function was executing. |
4815 | 4992 |
4816 % Is this controversial? We were thinking of viewing the trace as a List<Invoca tion>, | 4993 % Is this controversial? We were thinking of viewing the trace as a List<Invoca tion>, |
4817 % but that won't capture the receiver or the locals. More generally, we need a standard interface that describes these traces, so one can type the stack trace variable in the catch. | 4994 % but that won't capture the receiver or the locals. More generally, we need a standard interface that describes these traces, so one can type the stack trace variable in the catch. |
4818 | 4995 |
4819 \commentary{The term position should not be interpreted as a line number, but r ather as a precise position - the exact character index of the expression that raised the exception. } | 4996 \commentary{The term position should not be interpreted as a line number, but r ather as a precise position - the exact character index of the expression that raised the exception. } |
4820 | 4997 |
4821 % A position can be represented via a Token. If we make that part of the core r eflection facility, we can state this here. | 4998 % A position can be represented via a Token. If we make that part of the core r eflection facility, we can state this here. |
4822 | |
4823 \rationale{The definition below is an attempt to characterize exception handlin g without resorting to a normal/abrupt completion formulation. It has the advant age that one need not specify abrupt completion behavior for every compound stat ement. On the other hand, it is new and different and needs more thought. | |
4824 } | |
4825 | |
4826 % so, we need to fix things so that returns in the try still go through the fina lly clause and so that | |
4827 % uncaught or rethrown exceptions propagate from the finally clause unless it r eturns. | |
4828 | |
4829 % plan: return transfers control to the enclosing finally clause if it exists an d erases | |
4830 % any current stack trace & exception. | |
4831 % But how to ensure return leaves the finally if it does not throw? special text ? say return | |
4832 % does the finally and then xfers control ? | |
4833 | 4999 |
4834 A try statement \TRY{} $s_1$ $on-catch_1 \ldots on-catch_n$ \FINALLY{} $s_f$ d efines an exception handler $h$ that executes as follows: | 5000 A try statement \TRY{} $s_1$ $on-catch_1 \ldots on-catch_n$ \FINALLY{} $s_f$ d efines an exception handler $h$ that executes as follows: |
4835 | 5001 |
4836 The \ON{}-\CATCH{} clauses are examined in order, starting with $catch_1$, until either an \ON{}-\CATCH{} clause that matches the current exception (\ref{throw} ) is found, or the list of \ON{}-\CATCH{} clauses has been exhausted. If an \ON{ }-\CATCH{} clause $on-catch_k$ is found, then $p_{k1}$ is bound to the current e xception, $p_{k2}$, if declared, is bound to the active stack trace, and then $catch_k$ is executed. If no \ON{}-\CATCH{} clause is found, the \FINALLY{} clau se is executed. Then, execution resumes at the end of the try statement. | 5002 The \ON{}-\CATCH{} clauses are examined in order, starting with $catch_1$, until either an \ON{}-\CATCH{} clause that matches the current exception (\ref{throw} ) is found, or the list of \ON{}-\CATCH{} clauses has been exhausted. If an \ON{ }-\CATCH{} clause $on-catch_k$ is found, then $p_{k1}$ is bound to the current e xception, $p_{k2}$, if declared, is bound to the active stack trace, and then $catch_k$ is executed. If no \ON{}-\CATCH{} clause is found, the \FINALLY{} clau se is executed. Then, execution resumes at the end of the try statement. |
4837 | 5003 |
4838 | 5004 |
4839 A finally clause \FINALLY{} $s$ defines an exception handler $h$ that executes b y executing the finally clause. | 5005 A finally clause \FINALLY{} $s$ defines an exception handler $h$ that executes a s follows: |
4840 % If the current exception is defined | |
4841 | 5006 |
4842 Then, execution resumes at the end of the try statement. | 5007 Let $r$ be the current return value (\ref{return}). Then the current return valu e becomes undefined. Any open streams associated with any asynchronous for loops (\ref{asynchronousFor-in}) and yield-each (\ref{yieldEach}) statements executin g within the dynamic scope of $h$ are canceled. |
5008 | |
5009 \rationale{ | |
5010 Streams left open by for loops that were escaped for whatever reason would be ca nceled at function termination, but it is best to cancel them as soon as possibl e. | |
5011 } | |
5012 | |
5013 Then the \FINALLY{} clause is executed. Let $m$ be the immediately enclosing fun ction. If $r$ is defined then the current return value is set to $r$ and then: | |
5014 \begin{itemize} | |
5015 \item | |
5016 if there is a dynamically enclosing error handler $g$ defined by a \FINALLY{} c lause in $m$, control is transferred to $g$. | |
5017 \item | |
5018 Otherwise $m$ terminates. | |
5019 \end{itemize} | |
5020 | |
5021 Otherwise, execution resumes at the end of the try statement. | |
4843 | 5022 |
4844 Execution of an \ON{}-\CATCH{} clause \code{\ON{} $T$ \CATCH{} ($p_1$, $p_2$)} $ s$ of a try statement $t$ proceeds as follows: The statement $s$ is executed in the dynamic scope of the exception handler defined by the finally clause of $t$. Then, the current exception and active stack trace both become undefined. | 5023 Execution of an \ON{}-\CATCH{} clause \code{\ON{} $T$ \CATCH{} ($p_1$, $p_2$)} $ s$ of a try statement $t$ proceeds as follows: The statement $s$ is executed in the dynamic scope of the exception handler defined by the finally clause of $t$. Then, the current exception and active stack trace both become undefined. |
4845 | 5024 |
4846 Execution of a \FINALLY{} clause \FINALLY{} $s$ of a try statement proceeds as f ollows: | 5025 Execution of a \FINALLY{} clause \FINALLY{} $s$ of a try statement proceeds as f ollows: |
4847 | 5026 |
4848 The statement $s$ is executed. Then, if the current exception is defined, contro l is transferred to the nearest dynamically enclosing exception handler. | 5027 Let $x$ be the current exception and let $t$ be the active stack trace. Then the current exception and the active stack trace both become undefined. The stateme nt $s$ is executed. Then, if $x$ is defined, it is rethrown as if by a rethrow statement (\ref{rethrow}) enclosed in a \CATCH{} clause of the form \code{\CATCH {} ($v_x$, $v_t$)} where $v_x$ and $v_t$ are fresh variables bound to $x$ and $t $ respectively. |
5028 | |
4849 | 5029 |
4850 Execution of a try statement of the form \code{\TRY{} $s_1$ $on-catch_1 \ldots o n-catch_n$ \FINALLY{} $s_f$;} proceeds as follows: | 5030 Execution of a try statement of the form \code{\TRY{} $s_1$ $on-catch_1 \ldots o n-catch_n$ \FINALLY{} $s_f$;} proceeds as follows: |
4851 | 5031 |
4852 The statement $s_1$ is executed in the dynamic scope of the exception handler de fined by the try statement. Then, the \FINALLY{} clause is executed. | 5032 The statement $s_1$ is executed in the dynamic scope of the exception handler de fined by the try statement. Then, the \FINALLY{} clause is executed. |
4853 | 5033 |
4854 \commentary{ | 5034 \commentary{ |
4855 Whether any of the \ON{}-\CATCH{} clauses is executed depends on whether a match ing exception has been raised by $s_1$ (see the specification of the throw state ment). | 5035 Whether any of the \ON{}-\CATCH{} clauses is executed depends on whether a match ing exception has been raised by $s_1$ (see the specification of the throw state ment). |
4856 | 5036 |
4857 If $s_1$ has raised an exception, it will transfer control to the try statement' s handler, which will examine the catch clauses in order for a match as specifie d above. If no matches are found, the handler will execute the \FINALLY{} clause . | 5037 If $s_1$ has raised an exception, it will transfer control to the try statement' s handler, which will examine the catch clauses in order for a match as specifie d above. If no matches are found, the handler will execute the \FINALLY{} clause . |
4858 | 5038 |
4859 If a matching \ON{}-\CATCH{} was found, it will execute first, and then the \FIN ALLY{} clause will be executed. | 5039 If a matching \ON{}-\CATCH{} was found, it will execute first, and then the \FIN ALLY{} clause will be executed. |
4860 | 5040 |
4861 If an exception is thrown during execution of an \ON{}-\CATCH{} clause, this wil l transfer control to the handler for the \FINALLY{} clause, causing the \FINALL Y{} clause to execute in this case as well. | 5041 If an exception is thrown during execution of an \ON{}-\CATCH{} clause, this wil l transfer control to the handler for the \FINALLY{} clause, causing the \FINALL Y{} clause to execute in this case as well. |
4862 | 5042 |
4863 If no exception was raised, the \FINALLY{} clause is also executed. Execution of the \FINALLY{} clause could also raise an exception, which will cause transfer of control to the next enclosing handler. | 5043 If no exception was raised, the \FINALLY{} clause is also executed. Execution of the \FINALLY{} clause could also raise an exception, which will cause transfer of control to the next enclosing handler. |
4864 } | 5044 } |
4865 | 5045 |
4866 A try statement of the form \code{\TRY{} $s_1$ $on-catch_1 \ldots on-catch_n$;} is equivalent to the statement \code{\TRY{} $s_1$ $on-catch_1 \ldots on-catch_n$ \FINALLY{} $\{\}$;}. | 5046 A try statement of the form \code{\TRY{} $s_1$ $on-catch_1 \ldots on-catch_n$;} is equivalent to the statement \code{\TRY{} $s_1$ $on-catch_1 \ldots on-catch_n$ \FINALLY{} $\{\}$}. |
4867 | 5047 |
4868 | 5048 |
4869 \subsection{ Return} | 5049 \subsection{ Return} |
4870 \label{return} | 5050 \label{return} |
4871 | 5051 |
4872 The {\em return statement} returns a result to the caller of a function. | 5052 The {\em return statement} returns a result to the caller of a synchronous funct ion, completes the future associated with an asynchronous function or terminate s the stream or iterable associated with a generator (\ref{functions}). |
5053 | |
4873 | 5054 |
4874 \begin{grammar} | 5055 \begin{grammar} |
4875 {\bf returnStatement:} | 5056 {\bf returnStatement:} |
4876 \RETURN{} expression? '{\escapegrammar ;}' % could do top level here | 5057 \RETURN{} expression? `{\escapegrammar ;}' % could do top level here |
4877 . | 5058 . |
4878 \end{grammar} | 5059 \end{grammar} |
5060 | |
5061 \commentary{ | |
5062 Due to \FINALLY{} clauses, the precise behavior of \RETURN{} is a little more i nvolved. Whether the value a return statement is supposed to return is actually returned depends on the behavior of any \FINALLY{} clauses in effect when execut ing the return. A \FINALLY{} clause may choose to return another value, or throw an exception, or even redirect control flow leading to other returns or throws. All a return statement really does is set a value that is intended to be return ed when the function terminates. | |
5063 } | |
5064 | |
5065 The {\em current return value} is a unique value specific to a given function ac tivation. It is undefined unless explicitly set in this specification. | |
4879 | 5066 |
4880 Executing a return statement | 5067 Executing a return statement \code{\RETURN{} $e$;} proceeds as follows: |
4881 | 5068 |
4882 \code{\RETURN{} $e$;} | 5069 First the expression $e$ is evaluated, producing an object $o$. Next: |
5070 \begin{itemize} | |
5071 \item | |
5072 The current return value is set to $o$ and the current exception (\ref{throw}) a nd active stack trace (\ref{try}) become undefined. | |
5073 \item | |
5074 Let $c$ be the \FINALLY{} clause of the innermost enclosing try-finally statemen t (\ref{try}), if any. If $c$ is defined, let $h$ be the handler induced by $c$. If $h$ is defined, control is transferred to $h$. | |
5075 \item | |
5076 Otherwise execution of the current method terminates. | |
5077 \end{itemize} | |
4883 | 5078 |
4884 first causes evaluation of the expression $e$, producing an object $o$. Next, co ntrol is transferred to the caller of the current function activation, and the o bject $o$ is provided to the caller as the result of the function call. | 5079 \commentary{ |
5080 In the simplest case, the immediately enclosing function is an ordinary, synchro nous non-generator, and upon function termination, the current return value is g iven to the caller. The other possibility is that the function is marked \ASYNC {}, in which case the current return value is used to complete the future associ ated with the function invocation. Both these scenarios are specified in section \ref{functionInvocation}. | |
5081 The enclosing function cannot be marked as generator (i.e, \ASYNC* or \SYNC*), s ince generators are not allowed to contain a statement of the form \code{\RETURN {} $e$;} as discussed below. | |
5082 } | |
4885 | 5083 |
4886 It is a static type warning if the type of $e$ may not be assigned to the declar ed return type of the immediately enclosing function. | 5084 Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing funct ion. |
4887 %It is a static warning if the immediately enclosing function of a return statem ent of the form \code{\RETURN{} $e$;} is \VOID{}. | |
4888 | 5085 |
4889 In checked mode, it is a dynamic type error if $o$ is not \NULL{} and the runtim e type of $o$ is not a subtype of the actual return type (\ref{actualTypeOfADecl aration}) of the immediately enclosing function. | 5086 It is a static type warning if the body of $f$ is marked \ASYNC{} and the type \ code{Future$<$flatten(T)$>$} (\ref{awaitExpressions}) may not be assigned to the declared return type of $f$. Otherwise, it is a static type warning if $T$ ma y not be assigned to the declared return type of $f$. |
5087 | |
5088 Let $S$ be the runtime type of $o$. In checked mode: | |
5089 \begin{itemize} | |
5090 \item If the body of $f$ is marked \ASYNC{} (\ref{functions}) it is a dynamic t ype error if $o$ is not \NULL{} (\ref{null}) and \code{Future$<$S$>$} is not a s ubtype of the actual return type (\ref{actualTypeOfADeclaration}) of $f$. | |
5091 \item Otherwise, it is a dynamic type error if $o$ is not \NULL{} and the runtim e type of $o$ is not a subtype of the actual return type of $f$. | |
5092 \end{itemize} | |
4890 | 5093 |
4891 It is a compile-time error if a return statement of the form \code{\RETURN{} $e$ ;} appears in a generative constructor (\ref{generativeConstructors}). | 5094 It is a compile-time error if a return statement of the form \code{\RETURN{} $e$ ;} appears in a generative constructor (\ref{generativeConstructors}). |
4892 | 5095 |
4893 \rationale{ | 5096 \rationale{ |
4894 It is quite easy to forget to add the factory prefix for a constructor, accident ally converting a factory into a generative constructor. The static checker may detect a type mismatch in some, but not all, of these cases. The rule above help s catch such errors, which can otherwise be very hard to recognize. There is no real downside to it, as returning a value from a generative constructor is meani ngless. | 5097 It is quite easy to forget to add the factory prefix for a constructor, accident ally converting a factory into a generative constructor. The static checker may detect a type mismatch in some, but not all, of these cases. The rule above help s catch such errors, which can otherwise be very hard to recognize. There is no real downside to it, as returning a value from a generative constructor is meani ngless. |
4895 } | 5098 } |
4896 | 5099 |
4897 Let $f$ be the function immediately enclosing a return statement of the form \RE TURN{}; It is a static warning if both of the following conditions hold: | 5100 It is a compile-time error if a return statement of the form \code{\RETURN{} $e$ ;} appears in a generator function. |
5101 | |
5102 \rationale{ | |
5103 In the case of a generator function, the value returned by the function is the i terable or stream associated with it, and individual elements are added to that iterable using yield statements, and so returning a value makes no sense. | |
5104 } | |
5105 | |
5106 Let $f$ be the function immediately enclosing a return statement of the form \RE TURN{}; It is a static warning $f$ is neither a generator nor a generative cons tructor and either: | |
4898 \begin{itemize} | 5107 \begin{itemize} |
4899 \item $f$ is not a generative constructor. | 5108 \item $f$ is synchronous and the return type of $f$ may not be assigned to \VOI D{} (\ref{typeVoid}) or, |
4900 \item The return type of $f$ may not be assigned to \VOID{}. | 5109 \item $f$ is asynchronous and the return type of $f$ may not be assigned to \co de{Future$<$Null$>$}. |
4901 \end{itemize} | 5110 \end{itemize} |
4902 | 5111 |
4903 \commentary{ | 5112 \commentary{ |
4904 Hence, a static warning will not be issued if $f$ has no declared return type, s ince the return type would be \DYNAMIC{} and \DYNAMIC{} may be assigned to \VO ID{}. However, any function that declares a return type must return an expressio n explicitly. | 5113 Hence, a static warning will not be issued if $f$ has no declared return type, s ince the return type would be \DYNAMIC{} and \DYNAMIC{} may be assigned to \VO ID{} and to \code{Future$<$Null$>$}. However, any synchronous non-generator func tion that declares a return type must return an expression explicitly. |
4905 } | 5114 } |
4906 | |
4907 \rationale{This helps catch situations where users forget to return a value in a return statement.} | 5115 \rationale{This helps catch situations where users forget to return a value in a return statement.} |
4908 | 5116 |
4909 A return statement of the form \code{\RETURN{};} is executed by executing the s tatement \code{\RETURN{} \NULL{};} if it occurs inside a method, getter, setter or factory; otherwise, the return statement necessarily occurs inside a generat ive constructor, in which case it is executed by executing \code{\RETURN{} \THI S{};}. | 5117 \rationale{ An asynchronous non-generator always returns a future of some sort. If no expression is given, the future will be completed with \NULL{} and this mo tivates the requirement above.} \commentary{Leaving the return type of a functio n marked \ASYNC{} blank will be interpreted as \DYNAMIC{} as always, and cause no type error. Using \code{Future} or \code{Future$<$Object$>$} is acceptable as well, but any other type will cause a warning, since \NULL{} has no subtypes.} |
5118 | |
5119 A return statement with no expression, \code{\RETURN;} is executed as follows: | |
5120 | |
5121 If the immediately enclosing function $f$ is a generator, then: | |
5122 \begin{itemize} | |
5123 \item | |
5124 The current return value is set to \NULL{}. | |
5125 \item | |
5126 Let $c$ be the \FINALLY{} clause of the innermost enclosing try-finally statemen t, if any. If $c$ is defined, let $h$ be the handler induced by $c$. If $h$ is defined, control is transferred to $h$. | |
5127 \item | |
5128 Otherwise, execution of the current method terminates. | |
5129 \end{itemize} | |
5130 | |
5131 Otherwise the return statement is executed by executing the statement \code{\RE TURN{} \NULL{};} if it occurs inside a method, getter, setter or factory; otherw ise, the return statement necessarily occurs inside a generative constructor, in which case it is executed by executing \code{\RETURN{} \THIS{};}. | |
4910 | 5132 |
4911 \commentary{Despite the fact that \code{\RETURN{};} is executed as if by a \code {\RETURN{} $e$;}, it is important to understand that it is not a static warning to include a statement of the form \code{\RETURN{};} | 5133 \commentary{Despite the fact that \code{\RETURN{};} is executed as if by a \code {\RETURN{} $e$;}, it is important to understand that it is not a static warning to include a statement of the form \code{\RETURN{};} |
4912 %in a \VOID{} function; neither is it illegal | 5134 %in a \VOID{} function; neither is it illegal |
4913 in a generative constructor. The rules relate only to the specific syntactic for m \code{\RETURN{} $e$;}. | 5135 in a generative constructor. The rules relate only to the specific syntactic for m \code{\RETURN{} $e$;}. |
4914 } | 5136 } |
4915 | 5137 |
4916 | 5138 |
4917 \rationale{ | 5139 \rationale{ |
4918 The motivation for formulating \code{\RETURN{};} in this way stems from the basi c requirement that all function invocations indeed return a value. Function invo cations are expressions, and we cannot rely on a mandatory typechecker to always prohibit use of \VOID{} functions in expressions. Hence, a return statement mus t always return a value, even if no expression is specified. | 5140 The motivation for formulating \code{\RETURN{};} in this way stems from the basi c requirement that all function invocations indeed return a value. Function invo cations are expressions, and we cannot rely on a mandatory typechecker to always prohibit use of \VOID{} functions in expressions. Hence, a return statement mus t always return a value, even if no expression is specified. |
4919 | 5141 |
4920 The question then becomes, what value should a return statement return when no r eturn expression is given. In a generative constructor, it is obviously the obje ct being constructed (\THIS{}). A void function is not expected to participate i n an expression, which is why it is marked \VOID{} in the first place. Hence, th is situation is a mistake which should be detected as soon as possible. The stat ic rules help here, but if the code is executed, using \NULL{} leads to fast fai lure, which is desirable in this case. The same rationale applies for function b odies that do not contain a return statement at all. | 5142 The question then becomes, what value should a return statement return when no r eturn expression is given. In a generative constructor, it is obviously the obje ct being constructed (\THIS{}). A void function is not expected to participate i n an expression, which is why it is marked \VOID{} in the first place. Hence, th is situation is a mistake which should be detected as soon as possible. The stat ic rules help here, but if the code is executed, using \NULL{} leads to fast fai lure, which is desirable in this case. The same rationale applies for function b odies that do not contain a return statement at all. |
4921 } | 5143 } |
4922 | 5144 |
4923 It is a static warning if a function contains both one or more explicit return s tatements of the form \code{\RETURN;} and one or more return statements of the f orm \code{\RETURN{} $e$;}. | 5145 It is a static warning if a function contains both one or more explicit return statements of the form \code{\RETURN;} and one or more return statements of the form \code{\RETURN{} $e$;}. |
5146 | |
5147 | |
4924 | 5148 |
4925 | 5149 |
4926 \subsection{ Labels} | 5150 \subsection{ Labels} |
4927 \label{labels} | 5151 \label{labels} |
4928 | 5152 |
4929 A {\em label} is an identifier followed by a colon. A {\em labeled statement} is a statement prefixed by a label $L$. A {\em labeled case clause} is a case cla use within a switch statement (\ref{switch}) prefixed by a label $L$. | 5153 A {\em label} is an identifier followed by a colon. A {\em labeled statement} is a statement prefixed by a label $L$. A {\em labeled case clause} is a case cla use within a switch statement (\ref{switch}) prefixed by a label $L$. |
4930 | 5154 |
4931 \rationale{The sole role of labels is to provide targets for the break (\ref{bre ak}) and continue (\ref{continue}) statements.} | 5155 \rationale{The sole role of labels is to provide targets for the break (\ref{bre ak}) and continue (\ref{continue}) statements.} |
4932 | 5156 |
4933 %\Q{Are labels in a separate namespace? Bug 49774299} | 5157 %\Q{Are labels in a separate namespace? Bug 49774299} |
4934 | 5158 |
4935 \begin{grammar} | 5159 \begin{grammar} |
4936 {\bf label:} | 5160 {\bf label:} |
4937 identifier '{\escapegrammar :}' | 5161 identifier `{\escapegrammar :}' |
4938 . | 5162 . |
4939 \end{grammar} | 5163 \end{grammar} |
4940 | 5164 |
4941 The semantics of a labeled statement $L: s$ are identical to those of the state ment $s$. The namespace of labels is distinct from the one used for types, funct ions and variables. | 5165 The semantics of a labeled statement $L: s$ are identical to those of the state ment $s$. The namespace of labels is distinct from the one used for types, funct ions and variables. |
4942 | 5166 |
4943 The scope of a label that labels a statement $s$ is $s$. The scope of a label th at labels a case clause of a switch statement $s$ is $s$. | 5167 The scope of a label that labels a statement $s$ is $s$. The scope of a label th at labels a case clause of a switch statement $s$ is $s$. |
4944 | 5168 |
4945 \rationale{Labels should be avoided by programmers at all costs. The motivation for including labels in the language is primarily making Dart a better target fo r code generation. | 5169 \rationale{Labels should be avoided by programmers at all costs. The motivation for including labels in the language is primarily making Dart a better target fo r code generation. |
4946 } | 5170 } |
4947 | 5171 |
4948 | 5172 |
4949 \subsection{ Break} | 5173 \subsection{ Break} |
4950 \label{break} | 5174 \label{break} |
4951 | 5175 |
4952 The {\em break statement} consists of the reserved word \BREAK{} and an optional label (\ref{labels}). | 5176 The {\em break statement} consists of the reserved word \BREAK{} and an optional label (\ref{labels}). |
4953 | 5177 |
4954 \begin{grammar} | 5178 \begin{grammar} |
4955 {\bf breakStatement:} | 5179 {\bf breakStatement:} |
4956 \BREAK{} identifier? '{\escapegrammar ;}' | 5180 \BREAK{} identifier? `{\escapegrammar ;}' |
4957 . | 5181 . |
4958 \end{grammar} | 5182 \end{grammar} |
4959 | 5183 |
4960 Let $s_b$ be a \BREAK{} statement. If $s_b$ is of the form \code{\BREAK{} $L$;} , then let $s_E$ be the the innermost labeled statement with label $L$ enclosing $s_b$. If $s_b$ is of the form \code{\BREAK{};}, then let $s_E$ be the the inn ermost \DO{} (\ref{do}), \FOR{} (\ref{for}), \SWITCH{} (\ref{switch}) or \WHILE {} (\ref{while}) statement enclosing $s_b$. It is a compile-time error if no su ch statement $s_E$ exists within the innermost function in which $s_b$ occurs. Furthermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both en closed in $s_E$ and that enclose $s_b$, and that have a \FINALLY{} clause. Last ly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$. Executing $s_ b$ first executes $f_1, \ldots, f_n$ in innermost-clause-first order and then terminates $s_E$. | 5184 Let $s_b$ be a \BREAK{} statement. If $s_b$ is of the form \code{\BREAK{} $L$;} , then let $s_E$ be the the innermost labeled statement with label $L$ enclosing $s_b$. If $s_b$ is of the form \code{\BREAK{};}, then let $s_E$ be the the inn ermost \DO{} (\ref{do}), \FOR{} (\ref{for}), \SWITCH{} (\ref{switch}) or \WHILE {} (\ref{while}) statement enclosing $s_b$. It is a compile-time error if no su ch statement $s_E$ exists within the innermost function in which $s_b$ occurs. Furthermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both en closed in $s_E$ and that enclose $s_b$, and that have a \FINALLY{} clause. Last ly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$. Executing $s_ b$ first executes $f_1, \ldots, f_n$ in innermost-clause-first order and then terminates $s_E$. |
4961 | 5185 |
5186 If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), its associated stream subscription is canceled. Furthermore, let $a_k$ be the set of asynchrono us for loops and yield-each statements (\ref{yieldEach}) enclosing $s_b$ that a re enclosed in $s_E , 1 \le k \le m$. The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$. | |
5187 | |
5188 | |
4962 | 5189 |
4963 \subsection{ Continue} | 5190 \subsection{ Continue} |
4964 \label{continue} | 5191 \label{continue} |
4965 | 5192 |
4966 The {\em continue statement} consists of the reserved word \CONTINUE{} and an op tional label (\ref{labels}). | 5193 The {\em continue statement} consists of the reserved word \CONTINUE{} and an op tional label (\ref{labels}). |
4967 | 5194 |
4968 \begin{grammar} | 5195 \begin{grammar} |
4969 {\bf continueStatement:} | 5196 {\bf continueStatement:} |
4970 \CONTINUE{} identifier? '{\escapegrammar ;}' | 5197 \CONTINUE{} identifier? `{\escapegrammar ;}' |
4971 . | 5198 . |
4972 \end{grammar} | 5199 \end{grammar} |
4973 | 5200 |
4974 Let $s_c$ be a \CONTINUE{} statement. If $s_c$ is of the form \code{\CONTINUE{ } $L$;}, then let $s_E$ be the the innermost labeled \DO{} (\ref{do}), \FOR{} (\ ref{for}) or \WHILE{} (\ref{while}) statement or case clause with label $L$ encl osing $s_c$. If $s_c$ is of the form \code{\CONTINUE{};} then let $s_E$ be the the innermost \DO{} (\ref{do}), \FOR{} (\ref{for}) or \WHILE{} (\ref{while}) st atement enclosing $s_c$. It is a compile-time error if no such statement or cas e clause $s_E$ exists within the innermost function in which $s_c$ occurs. Fur thermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both enclos ed in $s_E$ and that enclose $s_c$, and that have a \FINALLY{} clause. Lastly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$. Executing $s_c$ f irst executes $f_1, \ldots, f_n$ in innermost-clause-first order. Then, if $s_ E$ is a case clause, control is transferred to the case clause. Otherwise, $s_E$ is necessarily a loop and execution resumes after the last statement in the loo p body. | 5201 Let $s_c$ be a \CONTINUE{} statement. If $s_c$ is of the form \code{\CONTINUE{ } $L$;}, then let $s_E$ be the the innermost labeled \DO{} (\ref{do}), \FOR{} (\ ref{for}) or \WHILE{} (\ref{while}) statement or case clause with label $L$ encl osing $s_c$. If $s_c$ is of the form \code{\CONTINUE{};} then let $s_E$ be the the innermost \DO{} (\ref{do}), \FOR{} (\ref{for}) or \WHILE{} (\ref{while}) st atement enclosing $s_c$. It is a compile-time error if no such statement or cas e clause $s_E$ exists within the innermost function in which $s_c$ occurs. Fur thermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both enclos ed in $s_E$ and that enclose $s_c$, and that have a \FINALLY{} clause. Lastly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$. Executing $s_c$ f irst executes $f_1, \ldots, f_n$ in innermost-clause-first order. Then, if $s_ E$ is a case clause, control is transferred to the case clause. Otherwise, $s_E$ is necessarily a loop and execution resumes after the last statement in the loo p body. |
4975 | 5202 |
4976 \commentary{ | 5203 \commentary{ |
4977 In a while loop, that would be the boolean expression before the body. In a do loop, it would be the boolean expression after the body. In a for loop, it would be the increment clause. In other words, execution continues to the next itera tion of the loop. | 5204 In a while loop, that would be the boolean expression before the body. In a do loop, it would be the boolean expression after the body. In a for loop, it would be the increment clause. In other words, execution continues to the next itera tion of the loop. |
4978 } | 5205 } |
4979 | 5206 |
5207 If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), let $a_k$ be t he set of asynchronous for loops and yield-each statements (\ref{yieldEach}) enc losing $s_c$ that are enclosed in $s_E , 1 \le k \le m$. The stream subscripti ons associated with $a_j$ are canceled, $1 \le j \le m$. | |
5208 | |
5209 \subsection{ Yield and Yield-Each} | |
5210 \label{yieldAndYieldEach} | |
5211 | |
5212 \subsubsection{ Yield} | |
5213 \label{yield} | |
5214 | |
5215 The {\em yield statement} adds an element to the result of a generator function (\ref{functions}). | |
5216 | |
5217 \begin{grammar} | |
5218 {\bf yieldStatement:} | |
5219 \YIELD{} expression `{\escapegrammar ;}' | |
5220 . | |
5221 \end{grammar} | |
5222 | |
5223 Execution of a statement $s$ of the form \code{\YIELD{} $e$;} proceeds as follo ws: | |
5224 | |
5225 First, the expression $e$ is evaluated to an object $o$. If the enclosing functi on $m$ is marked \ASYNC* (\ref{functions}) and the stream $u$ associated with $m $ has been paused, then execution of $m$ is suspended until $u$ is resumed or c anceled. | |
5226 | |
5227 Next, $o$ is added to the iterable or stream associated with the immediately enc losing function. | |
5228 | |
5229 If the enclosing function $m$ is marked \ASYNC* and the stream $u$ associated wi th $m$ has been canceled, then let $c$ be the \FINALLY{} clause (\ref{try}) of t he innermost enclosing try-finally statement, if any. If $c$ is defined, let $h$ be the handler induced by $c$. If $h$ is defined, control is transferred to $h$ . If $h$ is undefined, the immediately enclosing function terminates. | |
5230 | |
5231 \rationale{ | |
5232 The stream associated with an asynchronous generator could be canceled by any co de with a reference to that stream at any point where the generator was passivat ed. Such a cancellation constitutes an irretrievable error for the generator. A t this point, the only plausible action for the generator is to clean up after i tself via its \FINALLY{} clauses. | |
5233 } | |
5234 | |
5235 If the enclosing function $m$ is marked \SYNC* (\ref{functions}) then: | |
5236 \begin{itemize} | |
5237 \item | |
5238 Execution of the function $m$ immediately enclosing $s$ is suspended until the m ethod \code{moveNext()} is invoked upon the iterator used to initiate the curren t invocation of $m$. | |
5239 \item | |
5240 The current call to \code{moveNext()} returns \TRUE. | |
Lasse Reichstein Nielsen
2014/09/10 09:22:00
Just noticed that the use of the value is missing,
| |
5241 \end{itemize} | |
5242 | |
5243 It is a compile-time error if a yield statement appears in a function that is no t a generator function. | |
5244 | |
5245 Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing funct ion. It is a static type warning if either: | |
5246 \begin{itemize} | |
5247 \item | |
5248 the body of $f$ is marked \ASYNC* and the type \code{Stream$<$T$>$} may not be assigned to the declared return type of $f$. | |
5249 \item | |
5250 the body of $f$ is marked \SYNC* and the type \code{Iterable$<$T$>$} may not be assigned to the declared return type of $f$. | |
5251 \end{itemize} | |
5252 | |
5253 | |
5254 \subsubsection{ Yield-Each} | |
5255 \label{yieldEach} | |
5256 | |
5257 The {\em yield-each statement} adds a series of values to the result of a gener ator function (\ref{functions}). | |
5258 | |
5259 \begin{grammar} | |
5260 {\bf yieldEachStatement:} | |
5261 \YIELD* expression `{\escapegrammar ;}' | |
5262 . | |
5263 \end{grammar} | |
5264 | |
5265 Execution of a statement s of the form \code{\YIELD* $e$;} proceeds as follows: | |
5266 | |
5267 First, the expression $e$ is evaluated to an object $o$. If the immediately encl osing function $m$ is synchronous, then it is a dynamic error if the class of $o $ does not implement \code{Iterable}. If $m$ asynchronous, then it is a dynamic error if the class of $o$ does not implement \code{Stream}. Next, for each elem ent $x$ of $o$: | |
Lasse Reichstein Nielsen
2014/09/10 09:22:00
Still not sure we want to require the types in unc
| |
5268 \begin{itemize} | |
5269 \item | |
5270 If $m$ is marked \ASYNC* (\ref{functions}) and the stream $u$ associated with $m $ has been paused, then execution of $m$ is suspended until $u$ is resumed or c anceled. | |
Lasse Reichstein Nielsen
2014/09/10 09:22:00
If $u$ is paused, then the subscription on $o$ sho
| |
5271 \item | |
5272 $x$ is added to the iterable or stream associated with $m$ in the order it appe ars in $o$. | |
5273 \item | |
5274 If $m$ is marked \ASYNC* and the stream $u$ associated with $m$ has been cancele d, then let $c$ be the \FINALLY{} clause (\ref{try}) of the innermost enclosing try-finally statement, if any. If $c$ is defined, let $h$ be the handler induce d by $c$. If $h$ is defined, control is transferred to $h$. If $h$ is undefined, the immediately enclosing function terminates. | |
5275 \end{itemize} | |
5276 | |
5277 If the enclosing function is marked \SYNC* (\ref{functions}) then: | |
5278 \begin{itemize} | |
5279 \item | |
5280 Execution of the function $m$ immediately enclosing $s$ is suspended until the m ethod \code{moveNext()} is invoked upon the iterator used to initiate the curren t invocation of $m$. | |
5281 \item | |
5282 The current call to \code{moveNext()} returns \TRUE. | |
5283 \end{itemize} | |
Lasse Reichstein Nielsen
2014/09/10 09:22:00
and `current` returns $x$ until the next call to `
| |
5284 | |
5285 It is a compile-time error if a yield-each statement appears in a function that is not a generator function. | |
5286 | |
5287 Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing funct ion. It is a static type warning if $T$ may not be assigned to the declared ret urn type of $f$. | |
5288 | |
4980 | 5289 |
4981 \subsection{ Assert} | 5290 \subsection{ Assert} |
4982 \label{assert} | 5291 \label{assert} |
4983 | 5292 |
4984 An {\em assert statement} is used to disrupt normal execution if a given boolean condition does not hold. | 5293 An {\em assert statement} is used to disrupt normal execution if a given boolean condition does not hold. |
4985 | 5294 |
4986 \begin{grammar} | 5295 \begin{grammar} |
4987 {\bf assertStatement:} | 5296 {\bf assertStatement:} |
4988 assert '(' conditionalExpression ')' '{\escapegrammar ;}' | 5297 assert `(' conditionalExpression `)' `{\escapegrammar ;}' |
4989 . | 5298 . |
4990 \end{grammar} | 5299 \end{grammar} |
4991 | 5300 |
4992 The assert statement has no effect in production mode. In checked mode, executio n of an assert statement \code{\ASSERT{}($e$);} proceeds as follows: | 5301 The assert statement has no effect in production mode. In checked mode, executio n of an assert statement \code{\ASSERT{}($e$);} proceeds as follows: |
4993 | 5302 |
4994 The conditional expression $e$ is evaluated to an object $o$. If the class of $o $ is a subtype of \code{Function} then let $r$ be the result of invoking $o$ wit h no arguments. Otherwise, let $r$ be $o$. | 5303 The conditional expression $e$ is evaluated to an object $o$. If the class of $o $ is a subtype of \code{Function} then let $r$ be the result of invoking $o$ wit h no arguments. Otherwise, let $r$ be $o$. |
4995 It is a dynamic type error if $o$ is not of type \code{bool} or of type \code{Fu nction}, or if $r$ is not of type \code{bool}. If $r$ is \FALSE{}, we say that the assertion failed. If $r$ is \TRUE{}, we say that the assertion succeeded. If the assertion succeeded, execution of the assert statement is complete. If the assertion failed, an \code{AssertionError} is thrown. | 5304 It is a dynamic type error if $o$ is not of type \code{bool} or of type \code{Fu nction}, or if $r$ is not of type \code{bool}. If $r$ is \FALSE{}, we say that the assertion failed. If $r$ is \TRUE{}, we say that the assertion succeeded. If the assertion succeeded, execution of the assert statement is complete. If the assertion failed, an \code{AssertionError} is thrown. |
4996 | 5305 |
4997 %\Q{Might be cleaner to define it as \code{if (!$e$) \{\THROW{} \NEW{} Assertion Error();\}} (in checked mode only). | 5306 %\Q{Might be cleaner to define it as \code{if (!$e$) \{\THROW{} \NEW{} Assertion Error();\}} (in checked mode only). |
4998 %What about an error message as part of the assert?} | 5307 %What about an error message as part of the assert?} |
(...skipping 308 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
5307 A library $L$ exports a namespace (\ref{scoping}), meaning that the declarations in the namespace are made available to other libraries if they choose to import $L$ (\ref{imports}). The namespace that $L$ exports is known as its {\em expor ted namespace}. | 5616 A library $L$ exports a namespace (\ref{scoping}), meaning that the declarations in the namespace are made available to other libraries if they choose to import $L$ (\ref{imports}). The namespace that $L$ exports is known as its {\em expor ted namespace}. |
5308 | 5617 |
5309 \begin{grammar} | 5618 \begin{grammar} |
5310 {\bf libraryExport:} | 5619 {\bf libraryExport:} |
5311 metadata \EXPORT{} uri combinator* `{\escapegrammar ;}' | 5620 metadata \EXPORT{} uri combinator* `{\escapegrammar ;}' |
5312 . | 5621 . |
5313 \end{grammar} | 5622 \end{grammar} |
5314 | 5623 |
5315 An export specifies a URI $x$ where the declaration of an exported library is t o be found. It is a compile-time error if the specified URI does not refer to a library declaration. | 5624 An export specifies a URI $x$ where the declaration of an exported library is t o be found. It is a compile-time error if the specified URI does not refer to a library declaration. |
5316 | 5625 |
5317 We say that a name {\em is exported by a library} (or equivalently, that a libra ry {\em exports a name}) if the name is in the library's exported namespace. We say that a declaration {\em is exported by a library} (or equivalently, that a l ibrary {\em exports a declaration}) if the declaration is in the library`s expor ted namespace. | 5626 We say that a name {\em is exported by a library} (or equivalently, that a libra ry {\em exports a name}) if the name is in the library's exported namespace. We say that a declaration {\em is exported by a library} (or equivalently, that a l ibrary {\em exports a declaration}) if the declaration is in the library's expor ted namespace. |
5318 | 5627 |
5319 A library always exports all names and all declarations in its public namespace. In addition, a library may choose to re-export additional libraries via {\em ex port directives}, often referred to simply as {\em exports}. | 5628 A library always exports all names and all declarations in its public namespace. In addition, a library may choose to re-export additional libraries via {\em ex port directives}, often referred to simply as {\em exports}. |
5320 | 5629 |
5321 Let $E$ be an export directive that refers to a URI via the string $s_1$. Evalua tion of $E$ proceeds as follows: | 5630 Let $E$ be an export directive that refers to a URI via the string $s_1$. Evalua tion of $E$ proceeds as follows: |
5322 | 5631 |
5323 First, | 5632 First, |
5324 | 5633 |
5325 \begin{itemize} | 5634 \begin{itemize} |
5326 \item | 5635 \item |
5327 If the URI that is the value of $s_1$ has not yet been accessed by an import or export directive in the current isolate then the contents of the URI are comp iled to yield a library $B$. | 5636 If the URI that is the value of $s_1$ has not yet been accessed by an import or export directive in the current isolate then the contents of the URI are comp iled to yield a library $B$. |
(...skipping 275 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
5603 does not cause a dynamic error, as there is no need to test against \code{I$<$St ring$>$} in this case. | 5912 does not cause a dynamic error, as there is no need to test against \code{I$<$St ring$>$} in this case. |
5604 Similarly, in production mode | 5913 Similarly, in production mode |
5605 } | 5914 } |
5606 | 5915 |
5607 \begin{dartCode} | 5916 \begin{dartCode} |
5608 A x = \NEW{} A$<$String$>$(); | 5917 A x = \NEW{} A$<$String$>$(); |
5609 bool b = x is I; | 5918 bool b = x is I; |
5610 \end{dartCode} | 5919 \end{dartCode} |
5611 | 5920 |
5612 \commentary{ | 5921 \commentary{ |
5613 \code{b} is bound to true, but in checked mode the second line causes a dynamic type error. | 5922 \code{b} is bound to \TRUE, but in checked mode the second line causes a dynamic type error. |
5614 } | 5923 } |
5615 | 5924 |
5616 | 5925 |
5617 | 5926 |
5618 \subsection{Type Declarations} | 5927 \subsection{Type Declarations} |
5619 \label{typeDeclarations} | 5928 \label{typeDeclarations} |
5620 | 5929 |
5621 \subsubsection{Typedef} | 5930 \subsubsection{Typedef} |
5622 \label{typedef} | 5931 \label{typedef} |
5623 | 5932 |
(...skipping 491 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
6115 \item The names of compile time constant variables never use lower case letters. If they consist of multiple words, those words are separated by underscores. Ex amples: PI, I\_AM\_A\_CONSTANT. | 6424 \item The names of compile time constant variables never use lower case letters. If they consist of multiple words, those words are separated by underscores. Ex amples: PI, I\_AM\_A\_CONSTANT. |
6116 \item The names of functions (including getters, setters, methods and local or l ibrary functions) and non-constant variables begin with a lowercase letter. If t he name consists of multiple words, each word (except the first) begins with an uppercase letter. No other uppercase letters are used. Examples: camlCase, dar t4TheWorld | 6425 \item The names of functions (including getters, setters, methods and local or l ibrary functions) and non-constant variables begin with a lowercase letter. If t he name consists of multiple words, each word (except the first) begins with an uppercase letter. No other uppercase letters are used. Examples: camlCase, dar t4TheWorld |
6117 \item The names of types (including classes and type aliases) begin with an uppe r case letter. If the name consists of multiple words, each word begins with an uppercase letter. No other uppercase letters are used. Examples: CamlCase, D art4TheWorld. | 6426 \item The names of types (including classes and type aliases) begin with an uppe r case letter. If the name consists of multiple words, each word begins with an uppercase letter. No other uppercase letters are used. Examples: CamlCase, D art4TheWorld. |
6118 \item The names of type variables are short (preferably single letter). Examples : T, S, K, V , E. | 6427 \item The names of type variables are short (preferably single letter). Examples : T, S, K, V , E. |
6119 \item The names of libraries or library prefixes never use upper case letters. I f they consist of multiple words, those words are separated by underscores. Exam ple: my\_favorite\_library. | 6428 \item The names of libraries or library prefixes never use upper case letters. I f they consist of multiple words, those words are separated by underscores. Exam ple: my\_favorite\_library. |
6120 \end{itemize} | 6429 \end{itemize} |
6121 } | 6430 } |
6122 | 6431 |
6123 | 6432 |
6124 \end{document} | 6433 \end{document} |
OLD | NEW |