@@ -2000,11 +2000,13 @@ \subsubsection{Required Formals}
2000
2000
an instance method, instance setter, or instance operator.
2001
2001
2002
2002
2003
- \subsubsection{Optional Formals}
2003
+ \subsubsection{Optional and Named Formals}
2004
2004
\LMLabel{optionalFormals}
2005
2005
2006
2006
\LMHash{}%
2007
- Optional parameters may be specified and provided with default values.
2007
+ Optional formal parameters may be specified and provided with default values.
2008
+ Named formal parameters can be optional,
2009
+ but if the modifier \REQUIRED{} is present then it is required.
2008
2010
2009
2011
\begin{grammar}
2010
2012
<defaultFormalParameter> ::= <normalFormalParameter> (`=' <expression>)?
@@ -2025,7 +2027,10 @@ \subsubsection{Optional Formals}
2025
2027
It is a compile-time error if the default value of an optional parameter is
2026
2028
not a constant expression (\ref{constants}).
2027
2029
If no default is explicitly specified for an optional parameter
2030
+ whose declared type is nullable,
2028
2031
an implicit default of \NULL{} is provided.
2032
+ Otherwise, when the declared type is not nullable,
2033
+ it is a compile-time error if an optional parameter has no default value.
2029
2034
2030
2035
\LMHash{}%
2031
2036
It is a compile-time error if the name of a named optional parameter
@@ -10245,7 +10250,45 @@ \subsubsection{Set and Map Literal Disambiguation}
10245
10250
\LMLabel{setAndMapLiteralDisambiguation}
10246
10251
10247
10252
\LMHash{}%
10248
- Some terms like \code{\{\}} and \code{\{\,...\id\,\}} are ambiguous:
10253
+ Some terms are syntactically ambiguous because they contain a \lit{?}
10254
+ which may be considered part of a nullable type
10255
+ or part of a \syntax{conditionalExpression}.
10256
+ In all such cases,
10257
+ the ambiguity is resolved in favor of the set literal
10258
+ and not the map literal.
10259
+
10260
+ \commentary{%
10261
+ In other words, conditional expressions are given preference.
10262
+ For example, \code{\{ a as bool ? - 3 : 3 \}} and
10263
+ \code{\{ a is int ? - 3 : 3 \}} are syntactically ambiguous
10264
+ in this manner.
10265
+ The former can be parsed as a set literal or as a map literal,
10266
+ depending on whether the \lit{?} is considered to make \code{bool} nullable,
10267
+ or it is considered as part of a conditional expression.
10268
+ The other expression has a similar ambiguity.
10269
+ They are both resolved to be set literals
10270
+ containing a conditional expression.%
10271
+ }
10272
+
10273
+ \LMHash{}%
10274
+ Similarly, null aware subscripts in conditional expressions
10275
+ can be syntactically ambiguous.
10276
+ Whenever there is a sequence of tokens
10277
+ which may be parsed either as a conditional expression
10278
+ or as two expressions separated by a colon,
10279
+ the first of which is a null aware subscript,
10280
+ parsers shall choose to parse as a conditional expression.
10281
+
10282
+ \commentary{%
10283
+ For example, \code{\{ a?[b]:c \}} can be parsed either as a set
10284
+ literal or a map literal, depending on whether the \lit{?} is
10285
+ interpreted as part of a null aware subscript or as part of a
10286
+ conditional expression.
10287
+ It is resolved as the latter.%
10288
+ }
10289
+
10290
+ \LMHash{}%
10291
+ Some terms like \code{\{\}} and \code{\{\,...\id\,\}} are still ambiguous:
10249
10292
they may be either a set literal or a map literal.
10250
10293
This ambiguity is eliminated in two steps.
10251
10294
The first step uses only the syntax and context type,
@@ -16329,8 +16372,7 @@ \subsection{Assignable Expressions}
16329
16372
from the end of $e$.
16330
16373
It is easy to see that only some \synt{assignableExpression}s
16331
16374
have a receiver term.
16332
- For instance, a plain \synt{identifier} does not.
16333
- %
16375
+ For instance, a plain \synt{identifier} does not.%
16334
16376
}
16335
16377
16336
16378
\LMHash{}%
@@ -19069,7 +19111,7 @@ \subsection{Imports}
19069
19111
\ref{exports}).
19070
19112
19071
19113
\LMHash{}%
19072
- The dart core library \code{dart:core}
19114
+ The Dart core library \code{dart:core}
19073
19115
is implicitly imported into every dart library other than itself
19074
19116
via an import clause of the form
19075
19117
\code{\IMPORT{} 'dart:core';}
@@ -21336,6 +21378,63 @@ \subsubsection{Additional Subtyping Concepts}
21336
21378
}
21337
21379
21338
21380
21381
+ \subsection{Type \code{Never}}
21382
+ \LMLabel{typeNever}
21383
+
21384
+ \LMHash{}%
21385
+ The Dart core library \code{dart:core} exports a type named \code{Never}.
21386
+ No object has dynamic type \code{Never}.
21387
+
21388
+ \commentary{%
21389
+ In other words, \code{Never} is the empty type.
21390
+ \code{Never} is a subtype of every other type in Dart
21391
+ (\ref{subtypeRules}).%
21392
+ }
21393
+
21394
+ \rationale{%
21395
+ \code{Never} is a useful type for several reasons:
21396
+ It can be used to indicate that
21397
+ the evaluation of an expression will never complete normally,
21398
+ e.g., because it calls a function that always throws.
21399
+ This allows for a more precise control flow analysis.
21400
+
21401
+ Also, the object \code{\CONST\,\,<Never>[]} can be used
21402
+ in any situation where a \code{List<$T$>} is required,
21403
+ for any $T$ whatsoever,
21404
+ and the value of a variable of type \code{Object?\,\,\FUNCTION(Never)}
21405
+ can be any function that accepts a single, positional argument.%
21406
+ }
21407
+
21408
+
21409
+ \subsection{Type \code{Null}}
21410
+ \LMLabel{typeNull}
21411
+
21412
+ \LMHash{}%
21413
+ The Dart core library \code{dart:core} exports a type named \code{Null},
21414
+ There is exactly one object whose dynamic type is \code{Null},
21415
+ and that is the null object.
21416
+
21417
+ \commentary{%
21418
+ In other words, \code{Null} is a singleton type.
21419
+ \code{Null} is a subtype of all other types
21420
+ other than \code{Never} and any type which is
21421
+ a subtype of \code{Never}
21422
+ (\ref{subtypeRules}).%
21423
+ }
21424
+
21425
+ \rationale{%
21426
+ \code{Null} is mainly used implicitly in
21427
+ a type of the form \code{$T$?} for some $T$.
21428
+ If $e$ is an expression of type \code{$T$?} that evaluates to an object $o$,
21429
+ then $o$ can be an instance of a subtype of $T$,
21430
+ or it could be the null object.
21431
+ The latter situation is commonly interpreted to mean that
21432
+ the computation did not yield a result.
21433
+ In this sense, \code{Null} can be considered to model
21434
+ the property of being optional.%
21435
+ }
21436
+
21437
+
21339
21438
\subsection{Function Types}
21340
21439
\LMLabel{functionTypes}
21341
21440
@@ -22398,94 +22497,8 @@ \subsection{Operator Precedence}
22398
22497
22399
22498
\section{Null safety} %% !!!TODO!!!
22400
22499
22401
- \newcommand{\FlattenName}{\metavar{flatten}}
22402
- \newcommand{\Flatten}[1]{\ensuremath{\FlattenName(\code{#1})}}
22403
-
22404
- \newcommand{\NnbdTopMergeName}{\metavar{topMerge}}
22405
- \newcommand{\NnbdTopMerge}[2]{\ensuremath{\NnbdTopMergeName(\code{{#1},\,\,{#2}})}}
22406
-
22407
- \newcommand{\NonNullTypeOfName}{\metavar{nonNullTypeOf}}
22408
- \newcommand{\NonNullTypeOf}[1]{\ensuremath{\NonNullTypeOfName(\code{#1})}}
22409
-
22410
- \newcommand{\IsTopTypeName}{\metavar{isTopType}}
22411
- \newcommand{\IsTopType}[1]{\ensuremath{\IsTopTypeName(\code{#1})}}
22412
-
22413
- \newcommand{\IsObjectTypeName}{\metavar{isObjectType}}
22414
- \newcommand{\IsObjectType}[1]{\ensuremath{\IsObjectTypeName(\code{#1})}}
22415
-
22416
- \newcommand{\IsBottomTypeName}{\metavar{isBottomType}}
22417
- \newcommand{\IsBottomType}[1]{\ensuremath{\IsBottomTypeName(\code{#1})}}
22418
-
22419
- \newcommand{\IsNullTypeName}{\metavar{isNullType}}
22420
- \newcommand{\IsNullType}[1]{\ensuremath{\IsNullTypeName(\code{#1})}}
22421
-
22422
- \newcommand{\IsMoreTopTypeName}{\metavar{isMoreTopType}}
22423
- \newcommand{\IsMoreTopType}[2]{\ensuremath{\IsMoreTopTypeName(\code{{#1},\,\,{#2}})}}
22424
-
22425
- \newcommand{\IsMoreBottomTypeName}{\metavar{isMoreBottomType}}
22426
- \newcommand{\IsMoreBottomType}[2]{\ensuremath{\IsMoreBottomTypeName(\code{{#1},\,\,{#2}})}}
22427
-
22428
- \newcommand{\NormalizedTypeOfName}{\metavar{normalizedTypeOf}}
22429
- \newcommand{\NormalizedTypeOf}[1]{\ensuremath{\NormalizedTypeOfName(\code{#1})}}
22430
-
22431
- \newcommand{\FutureValueTypeOfName}{\metavar{futureValueTypeOf}}
22432
- \newcommand{\FutureValueTypeOf}[1]{\ensuremath{\FutureValueTypeOfName(\code{#1})}}
22433
-
22434
-
22435
- \subsection{Syntax}
22436
-
22437
- The precise changes to the syntax are given in an accompanying set of
22438
- modifications to the grammar in the formal specification. This section
22439
- summarizes in prose the grammar changes associated with this feature.
22440
-
22441
- The grammar of types is extended to allow any type to be suffixed with a \code{?}
22442
- (e.g. \code{int?}) indicating the nullable version of that type.
22443
-
22444
- A new primitive type \code{Never}. This type is denoted by the built-in type
22445
- declaration \code{Never} declared in \code{dart:core}.
22446
-
22447
- The grammar of expressions is extended to allow any expression to be suffixed
22448
- with a \code{!}.
22449
-
22450
- The modifier \LATE{} is added as a built-in identifier. The grammar of top level
22451
- variables, static fields, instance fields, and local variables is extended to
22452
- allow any declaration to include the modifer \LATE.
22453
-
22454
- The modifier \REQUIRED{} is added as a built-in identifier. The grammar of
22455
- function types is extended to allow any named parameter declaration to be
22456
- prefixed by the \REQUIRED{} modifier
22457
- (e.g. \code{int \FUNCTION(int, {int? y, \REQUIRED\ int z})}).
22458
-
22459
- The grammar of selectors is extended to allow null-aware subscripting using the
22460
- syntax \code{$e_1$?[$e_2$]} which evaluates to \code{null} if \code{$e_1$} evaluates to \code{null} and
22461
- otherwise evaluates as \code{$e_1$[$e_2$]}.
22462
-
22463
- The grammar of cascade sequences is extended to allow the first cascade of a
22464
- sequence to be written as \code{?..} indicating that the cascade is null-shorting.
22465
-
22466
- \subsubsection{Grammatical ambiguities and clarifications}
22467
-
22468
- \paragraph{Conditional expression ambiguities}
22469
-
22470
- Conditional expressions inside of braces are ambiguous between sets and maps.
22471
- That is, \code{\{ a as bool ? - 3 : 3 \}} can be parsed as a set literal \code{\{ (a as bool)
22472
- ? - 3 : 3 \}} or as a map literal \code{\{ (a as bool ?) - 3 : 3 \}}. Parsers will
22473
- prefer the former parse over the latter.
22474
-
22475
- The same is true for \code{\{ a is int ? - 3 : 3 \}}.
22476
-
22477
- The same is true for \code{\{ int ? - 3 : 3 \}} if we allow this.
22478
-
22479
- \paragraph{Null aware subscript}
22480
-
22481
- Certain uses of null aware subscripts in conditional expressions are ambiguous.
22482
- For example, \code{\{ a?[b]:c \}} can be parsed either as a set literal or a map
22483
- literal, depending on whether the \code{?} is interpreted as part of a null aware
22484
- subscript or as part of a conditional expression. Whenever there is a sequence
22485
- of tokens which may be parsed either as a conditional expression or as two
22486
- expressions separated by a colon, the first of which is a null aware
22487
- subscript, parsers shall choose to parse as a conditional expression.
22488
-
22500
+ %% !!!At the end: Search Null, change to Never where appropriate
22501
+ %% !!!Search all `TODO`.*null
22489
22502
22490
22503
\subsection{Static semantics}
22491
22504
0 commit comments