Skip to content

Commit baacbb1

Browse files
authored
Clarify the void allowlist wrt [] and []= (#4454)
This PR adds a clarification to the `void` allowlist, specifying explicitly that `e1` can have type `void` in the case where `e0[e1]` is encountered and the statically known operator `[]` of `e1` has a parameter whose type is `void`, and similarly for `e0[e1] = e2` where both `e1` and `e2` can have type `void` when the corresponding formal parameters have type `void`. It also clarifies that the same rule applies to setters. Finally, it clarifies the item about local variable / parameter assignments. This PR also changes the word 'parameter' to 'argument' in the same item, in a location where it is clearly intended to refer to an actual argument, not a formal parameter. See also dart-lang/sdk#57071.
1 parent bca4110 commit baacbb1

File tree

1 file changed

+23
-5
lines changed

1 file changed

+23
-5
lines changed

specification/dartLangSpec.tex

Lines changed: 23 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -41,6 +41,10 @@
4141
% version of the language which will actually be specified by the next stable
4242
% release of this document.
4343
%
44+
% Jul 2025
45+
% - Clarify that operator `[]` and `[]=` are included in the `void` allowlist
46+
% rule about formal parameters of type `void`, and so are setters.
47+
%
4448
% May 2025
4549
% - Add `s?.length` as a constant expression in the case where `s` satisfies
4650
% some requirements.
@@ -22873,7 +22877,7 @@ \subsection{Type Void}
2287322877
may have type \VOID.
2287422878
\rationale{Usages of that variable are constrained.}
2287522879
\item
22876-
An actual parameter expression corresponding to a formal parameter
22880+
An actual argument expression corresponding to a formal parameter
2287722881
whose statically known type annotation is \VOID{}
2287822882
may have type \VOID.
2287922883
\rationale{%
@@ -22882,14 +22886,28 @@ \subsection{Type Void}
2288222886
See the discussion about soundness below
2288322887
(\ref{voidSoundness}).%
2288422888
}
22889+
This rule also applies to the operators \code{[]} and \code{[]=}.
22890+
\commentary{%
22891+
For example, $e_1$ and $e_2$ may have type \VOID{}
22892+
in an expression of the form \code{$e_0$[$e_1$] = $e_2$}
22893+
when the parameters of the statically known operator \code{[]=}
22894+
both have type \VOID{}.%
22895+
}
22896+
Finally, this rule also applies to setters.
22897+
\commentary{%
22898+
For example, with an expression of the form \code{$e_1$ = $e_2$}
22899+
which denotes a setter invocation whose
22900+
statically known parameter type is \VOID,
22901+
$e_2$ may have type \VOID{}.%
22902+
}
2288522903
\item
2288622904
In an expression of the form \code{$e_1$\,=\,$e_2$}
22887-
where $e_1$ is an \synt{assignableExpression}
22888-
denoting a variable or formal parameter of type \VOID,
22905+
where $e_1$ is an \synt{assignableExpression} denoting a local variable
22906+
\commentary{(which can also be a formal parameter)}
22907+
of type \VOID,
2288922908
$e_2$ may have type \VOID.
2289022909
\rationale{%
22891-
Usages of that variable or formal parameter
22892-
are statically expected to be constrained by having type \VOID.
22910+
Usages of that variable are constrained because it has type \VOID.
2289322911
See the discussion about soundness below
2289422912
(\ref{voidSoundness}).%
2289522913
}

0 commit comments

Comments
 (0)