|
104 | 104 | % - Add requirement that the iterator of a for-in statement must have
|
105 | 105 | % type `Iterator`.
|
106 | 106 | % - Clarify which constructors are covered by the section 'Constant
|
107 |
| -% Constructors' and removed confusing redundancy in definiton of |
| 107 | +% Constructors' and removed confusing redundancy in definition of |
108 | 108 | % potentially constant expressions.
|
109 | 109 | % - Integrate the feature specification of collection literal elements
|
110 | 110 | % (aka UI-as-code).
|
@@ -1717,7 +1717,7 @@ \subsection{Function Declarations}
|
1717 | 1717 | with the built-in identifier \STATIC{}.
|
1718 | 1718 |
|
1719 | 1719 | \LMHash{}%
|
1720 |
| -When we say that a function $f_1$ \Index{forwards} to another function $f_2$, |
| 1720 | +When we say that a function $f_1$ \Index{forwards} to another function $f_2$, |
1721 | 1721 | we mean that invoking $f_1$ causes $f_2$ to be executed
|
1722 | 1722 | with the same arguments and/or receiver as $f_1$,
|
1723 | 1723 | and returns the result of executing $f_2$ to the caller of $f_1$,
|
@@ -1952,7 +1952,7 @@ \subsubsection{Optional Formals}
|
1952 | 1952 | callers from outside the library where it was defined.
|
1953 | 1953 | If a method outside the library overrode a method with a private optional name,
|
1954 | 1954 | it would not be a subtype of the original method.
|
1955 |
| -The static checker would of course flag such situations, |
| 1955 | +The static checker would of course flag such situations, |
1956 | 1956 | but the consequence would be that adding a private named formal would break
|
1957 | 1957 | clients outside the library in a way they could not easily correct.%
|
1958 | 1958 | }
|
@@ -3432,7 +3432,7 @@ \subsubsection{Generative Constructors}
|
3432 | 3432 | \commentary{%
|
3433 | 3433 | This means that formal parameters, including initializing formals,
|
3434 | 3434 | must have distinct names, and that initializing formals
|
3435 |
| -are in scope for the initializer list, |
| 3435 | +are in scope for the initializer list, |
3436 | 3436 | but they are not in scope for the body of the constructor.
|
3437 | 3437 | When a formal parameter introduces a local variable into two scopes,
|
3438 | 3438 | it is still one variable and hence one storage location.
|
@@ -5230,7 +5230,7 @@ \subsection{Mixin Classes}
|
5230 | 5230 | % to be compile-time errors.
|
5231 | 5231 |
|
5232 | 5232 | \commentary{%
|
5233 |
| -It is an error, for example, if $M$ contains a member declaration $d$ |
| 5233 | +It is an error, for example, if $M$ contains a member declaration $d$ |
5234 | 5234 | which overrides a member signature $m$ in the interface of $S$,
|
5235 | 5235 | but which is not a correct override of $m$
|
5236 | 5236 | (\ref{correctMemberOverrides}).%
|
@@ -8254,7 +8254,7 @@ \subsection{Constants}
|
8254 | 8254 | % be computed statically without running user code.
|
8255 | 8255 |
|
8256 | 8256 | % A validly typed potentially constant expression can still fail when evaluated.
|
8257 |
| -% If that happens in a const invociation, it's a compile-time error. |
| 8257 | +% If that happens in a const invocation, it's a compile-time error. |
8258 | 8258 |
|
8259 | 8259 | \LMHash{}%
|
8260 | 8260 | It is a compile-time error if an expression is required to be
|
@@ -13772,7 +13772,7 @@ \subsubsection{Sending Messages}
|
13772 | 13772 | Messages are sent by invoking specific methods in the Dart libraries; there is no specific syntax for sending a message.
|
13773 | 13773 |
|
13774 | 13774 | \commentary{%
|
13775 |
| -In other words, the methods supporting sending messages |
| 13775 | +In other words, the methods supporting sending messages |
13776 | 13776 | embody primitives of Dart that are not accessible to ordinary code,
|
13777 | 13777 | much like the methods that spawn isolates.%
|
13778 | 13778 | }
|
@@ -16880,13 +16880,13 @@ \subsection{If}
|
16880 | 16880 |
|
16881 | 16881 | \rationale{%
|
16882 | 16882 | Under reasonable scope rules such code is problematic.
|
16883 |
| -If we assume that \code{v} is declared |
16884 |
| -in the scope of the method \code{main()}, |
16885 |
| -then when \code{somePredicate} is false, |
| 16883 | +If we assume that \code{v} is declared |
| 16884 | +in the scope of the method \code{main()}, |
| 16885 | +then when \code{somePredicate} is false, |
16886 | 16886 | \code{v} will be uninitialized when accessed.
|
16887 |
| -The cleanest approach would be to require a block following the test, |
| 16887 | +The cleanest approach would be to require a block following the test, |
16888 | 16888 | rather than an arbitrary statement.
|
16889 |
| -However, this goes against long standing custom, |
| 16889 | +However, this goes against long standing custom, |
16890 | 16890 | undermining Dart's goal of familiarity.
|
16891 | 16891 | Instead, we choose to insert a block, introducing a scope,
|
16892 | 16892 | around the statement following the predicate
|
@@ -17141,7 +17141,7 @@ \subsubsection{Asynchronous For-in}
|
17141 | 17141 | It is a compile-time error if a traditional for loop (\ref{forLoop}) is prefixed by the \AWAIT{} keyword.
|
17142 | 17142 |
|
17143 | 17143 | \rationale{%
|
17144 |
| -An asynchronous loop would make no sense within a synchronous function, |
| 17144 | +An asynchronous loop would make no sense within a synchronous function, |
17145 | 17145 | for the same reasons that an await expression makes no sense
|
17146 | 17146 | in a synchronous function.%
|
17147 | 17147 | }
|
@@ -18083,7 +18083,8 @@ \subsection{Yield-Each}
|
18083 | 18083 | if the class of $o$ is not a subtype of \code{Iterable<$T_f$>}.
|
18084 | 18084 | Otherwise
|
18085 | 18085 | \item
|
18086 |
| - The method \code{iterator} is invoked upon $o$ returning an object $i$. |
| 18086 | + The getter \code{iterator} is invoked upon $o$ returning an object $i$. |
| 18087 | + Otherwise |
18087 | 18088 | \item
|
18088 | 18089 | \label{moveNext} The \code{moveNext} method of $i$ is invoked on it
|
18089 | 18090 | with no arguments.
|
@@ -18117,35 +18118,76 @@ \subsection{Yield-Each}
|
18117 | 18118 | It is a dynamic type error if the class of $o$
|
18118 | 18119 | is not a subtype of \code{Stream<$T_f$>}.
|
18119 | 18120 | Otherwise
|
| 18121 | +\item |
| 18122 | + If the stream associated with $m$ has been cancelled, |
| 18123 | + then execution of $s$ completes by returning without a value. |
| 18124 | + \commentary{In this case, the \code{\YIELD*} operation does |
| 18125 | + not begin to listen to the stream $o$.} |
| 18126 | +Otherwise |
| 18127 | +\item |
| 18128 | + The $o$ stream is listened to by invoking \code{$v_o$.listen} |
| 18129 | + with system provided arguments, |
| 18130 | + where $v_o$ is a fresh variable referencing the stream $o$. |
| 18131 | + Let $u$ be the stream subscription returned by the call to |
| 18132 | + \code{$p$.listen} and let $v$ be a fresh variable bound to $u$. |
| 18133 | +\item |
| 18134 | + If the stream associated with $m$ is paused, then $u$ is immediately |
| 18135 | + paused as if by invoking \code{$v$.pause} with no arguments. |
| 18136 | +\item{} |
| 18137 | + If the stream associated with $m$ has been cancelled, then |
| 18138 | + $u$ is cancelled by executing \code{await $v$.cancel();}. |
| 18139 | + If this execution does not throw, the execution of $s$ |
| 18140 | + completes by returning without a value. |
| 18141 | + % This can only happen if a call to "listen" or "pause" above has |
| 18142 | + % side effects which cancels the stream of $m$. |
18120 | 18143 | \item
|
18121 | 18144 | The nearest enclosing asynchronous for loop (\ref{asynchronousFor-in}),
|
18122 | 18145 | if any, is paused.
|
18123 | 18146 | \item
|
18124 |
| - The $o$ stream is listened to, creating a subscription $s$, |
18125 |
| - and for each event $x$, or error $e$ with stack trace $t$, of $s$: |
| 18147 | + Execution of $m$ is suspended. |
| 18148 | + While $m$ is suspended, the following reactions happen if $u$ delivers |
| 18149 | + an event or if the stream associated with $m$ is paused, resumed or cancelled. |
| 18150 | + \commentary{It is unspecified what happens if $u$ delivers events |
| 18151 | + before $m$ is suspended or after $m$ is resumed, or if $u$ delivers events |
| 18152 | + after a call to \code{$v$.cancel} or a call to \code{$v$.pause} which has |
| 18153 | + not been followed by a call to \code{$v$.resume}, or after having delivered |
| 18154 | + a done event.} |
| 18155 | + % Such events should be ignored. |
18126 | 18156 | \begin{itemize}
|
18127 | 18157 | \item
|
18128 |
| - If the stream $u$ associated with $m$ has been paused, |
18129 |
| - then execution of $m$ is suspended until $u$ is resumed or canceled. |
| 18158 | + If the stream associated with $m$ becomes paused, |
| 18159 | + then $u$ is paused by executing \code{$v$.pause();}. |
| 18160 | + It is unspecified what happens if this execution throws. |
| 18161 | + % The error can be passed to \code{Zone.current.handleUncaughtError}. |
18130 | 18162 | \item
|
18131 |
| - If the stream $u$ associated with $m$ has been canceled, |
18132 |
| - then $s$ is canceled by evaluating \code{\AWAIT{} v.cancel()} |
18133 |
| - where $v$ is a fresh variable referencing the stream subscription $s$. |
18134 |
| - Then, if the cancel completed normally, |
18135 |
| - the stream execution of $s$ returns without an object |
18136 |
| - (\ref{statementCompletion}). |
| 18163 | + If the stream associated with $m$ is resumed after being paused, |
| 18164 | + then $u$ is resumed as by executing \code{$v$.resume();}. |
| 18165 | + It is unspecified what happens if this execution throws. |
| 18166 | + % The error can be passed to \code{Zone.current.handleUncaughtError}. |
| 18167 | + \item |
| 18168 | + If the stream associated with $m$ is cancelled, |
| 18169 | + then $u$ is also cancelled as by executing \code{await $v$.cancel();}. |
| 18170 | + |
| 18171 | + At some future time, execution of $m$ resumes. If the execution above |
| 18172 | + completed by throwing an error \metavar{er} and stack trace \metavar{st}, |
| 18173 | + then execution of $s$ completes by throwing \metavar{er} |
| 18174 | + and stack trace \metavar{st}. |
| 18175 | + Otherwise, execution of $s$ completes by returning without a value. |
18137 | 18176 | \item
|
18138 |
| - Otherwise, $x$, or $e$ with $t$, are added to |
18139 |
| - the stream associated with $m$ in the order they appear in $o$. |
18140 |
| - \commentary{% |
18141 |
| - Note that a dynamic error occurs if $x$ is added |
18142 |
| - and the dynamic type of $x$ is not a subtype of |
18143 |
| - the element type of said stream.% |
18144 |
| - } |
18145 |
| - The function $m$ may suspend. |
| 18177 | + If $u$ emits a data event with value $x$, |
| 18178 | + then if the runtime type of $x$ is not a subtype of $T_v$, |
| 18179 | + then the stream associated with $m$ emits a dynamic type error. |
| 18180 | + Otherwise the stream associated with $m$ immediately emits |
| 18181 | + a data event with value $x$. |
| 18182 | + \item |
| 18183 | + If $u$ emits an error event with error \metavar{er} |
| 18184 | + and stack trace \metavar{st}, |
| 18185 | + then the stream associated with $m$ immediately emits an error event |
| 18186 | + with error \metavar{er} and stack trace \metavar{st}. |
| 18187 | + \item |
| 18188 | + If $u$ closes \commentary{(by emitting a done event)}, |
| 18189 | + then execution of $m$ resumes and execution of $s$ completes normally. |
18146 | 18190 | \end{itemize}
|
18147 |
| -\item |
18148 |
| - If the stream $o$ is done, execution of $s$ completes normally. |
18149 | 18191 | \end{itemize}
|
18150 | 18192 |
|
18151 | 18193 |
|
|
0 commit comments