Dart语言规范2.2版：核心概念与特性解析

需积分: 5 113 浏览量更新于2024-07-10 收藏 1.18MB PDF 举报

"dart-spec-2-2.pdf 是 Dart 语言规范的第5版草案，版本2.2，发布于2019年7月29日。文档内容涵盖了Dart编程语言的各种方面，包括作用域、符合性、规范引用、术语定义、表示法、概述、错误与警告、变量、函数、类以及接口等。" Dart是一种面向对象的、动态类型的编程语言，由Google开发，广泛应用于Web和移动应用程序开发，特别是Flutter框架。在Dart 2.2的规范中，我们关注以下几个关键知识点： 1. **作用域(Scope)**：这部分讲述了变量和函数的作用范围，包括局部作用域（如在函数内部）、块作用域（如在{}内）和类成员作用域。理解作用域规则对于避免变量冲突和正确访问变量至关重要。 2. **隐私(Privacy)**：Dart支持公有、私有和包内可见的成员访问控制。公有成员可以在任何地方被访问，私有成员仅限于同一类内部访问，而包内可见的成员则限于同一包内的访问。 3. **并发(Concurrency)**：虽然Dart是单线程执行的，但它提供了异步编程的支持，如Future和async/await，使得开发者可以处理复杂的并发问题，实现非阻塞I/O操作。 4. **变量(Variables)**：Dart中的变量分为常量(const)和变量(var)，它们都有延迟初始化的特性。隐式变量获取意味着变量在首次使用时才会被计算。 5. **函数 Functions**：Dart允许声明函数，包括普通函数、外部函数（与Dart代码不直接关联的函数，如C++编译的库）。函数可以有必需参数、可选参数和协变参数，并且有类型注解。 6. **类(Classes)**：Dart是面向对象的语言，类是其核心部分。类可以有实例方法、静态方法、构造器、继承和接口实现。Dart支持生成式构造器、工厂构造器和常量构造器，以及覆盖和重载方法。 7. **接口 Interfaces**：Dart通过实现接口来提供多态性，类可以通过实现一个或多个接口来确保特定的方法集。接口也可以通过抽象类实现，抽象类可以包含抽象方法和非抽象方法。 8. **错误与警告(Errors and Warnings)**：这部分详细定义了Dart编译器和运行时可能抛出的错误和警告，这对于编写健壮的Dart代码是必要的。 Dart 2.2规范深入探讨了这些概念，为开发者提供了编写高效、可维护的Dart代码的指南。熟悉这些规范不仅有助于编写高质量的代码，也有助于理解和调试他人编写的Dart代码。

Dart Programming Language Speciﬁcation 16

A library variable introduces a getter into the top level scope of the enclosing

library. A static class variable introduces a static getter into the immediately

enclosing class. An instance variable introduces an instance getter into the

immediately enclosing class.

A mutable library variable introduces a setter into the top level scope of

the enclosing library. A mutable static class variable introduces a static setter

into the immediately enclosing class. A mutable instance variable introduces an

instance setter into the immediately enclosing class.

Let v be variable declared in an initializing variable declaration, and let e

be the associated initializing expression. It is a compile-time error if the static

type of e is not assignable to the declared type of v. It is a compile-time error

if a ﬁnal instance variable whose declaration has an initializer expression is also

initialized by a constructor, either by an initializing formal or an initializer list

entry.

It is a compile-time error if a ﬁnal instance variable that has been initialized by

means of an initializing formal of a constructor k is also initialized in the initializer

list of k (10.6.1).

A static ﬁnal variable v does not induce a setter, so unless a setter named v= is

in scope it is a compile-time error to assign to v.

Similarly, assignment to a ﬁnal instance variable v is a compile-time error, unless

a setter named v= is in scope, or the receiver has type dynamic. v can be initialized

in its declaration or in initializer lists, but initialization and assignment is not the

same thing. When the receiver has type dynamic such an assignment is not a

compile-time error, but if there is no setter it will cause a dynamic error.

A variable that has no initializing expression has the null object (16.4) as

its initial value. Otherwise, variable initialization proceeds as follows:

Static variable declarations with an initializing expression are initialized

lazily (8.1).

The lazy semantics are given because we do not want a language where one

tends to deﬁne expensive initialization computations, causing long application

startup times. This is especially crucial for Dart, which must support the coding

of client applications.

Initialization of an instance variable with no initializing expression takes place

during constructor execution (10.6.1).

Initialization of an instance variable v with an initializing expression e pro-

ceeds as follows: e is evaluated to an object o and the variable v is bound to

It is speciﬁed elsewhere when this initialization occurs, and in which environment

(p. 41, 17.3, 16.17.3).

If the initializing expression throws then access to the uninitialized variable is

prevented, because the instance creation that caused this initialization to take place

will throw.

It is a dynamic type error if the dynamic type of o is not a subtype of the

actual type of the variable v (19.10.1).

Dart Programming Language Speciﬁcation 17

8.1 Evaluation of Implicit Variable Getters

evaluationOfImplicitVariableGetters

Let d be the declaration of a static or instance variable v. If d is an instance

variable, then the invocation of the implicit getter of v evaluates to the value

stored in v. If d is a static variable (which can be a library variable) then the

implicit getter method of v executes as follows:

• Non-constant variable declaration with initializer. If d is of one of

the forms var v = e;, T v = e;, ﬁnal v = e;, ﬁnal T v = e;, static v

= e;, static T v = e; , static ﬁnal v = e; or static ﬁnal T v = e;

and no value has yet been stored into v then the initializing expression e

is evaluated. If, during the evaluation of e, the getter for v is invoked, a

CyclicInitializationError is thrown. If the evaluation of e throws an

exception e and stack trace s, the null object (16.4) is stored into v; the

execution of the getter then throws e and stack trace s. Otherwise, the

evaluation of e succeeded yielding an object o; then o is stored into v and

the execution of the getter completes by returning o. Otherwise, (when a

value o has been stored in v) execution of the getter completes by returning

• Constant variable declaration. If d is of one of the forms const v =

e;, const T v = e;, static const v = e; or static const T v = e; the

result of the getter is the value of the constant expression e. Note that a

constant expression cannot depend on itself, so no cyclic references can occur.

• Variable declaration without initializer. The result of executing the

getter method is the value stored in v. This may be the initial value, that

is, the null object.

9 Functions

functions

Functions abstract over executable actions.

hfunctionSignaturei ::=

hmetadatai htypei? hidentiﬁeri hformalParameterParti

hformalParameterParti ::= htypeParametersi? hformalParameterListi

hfunctionBodyi ::= async? ‘=>’ hexpressioni ‘;’

| (async | async‘*’ | sync‘*’)? hblocki

hblocki ::= ‘{’ hstatementsi ‘}’

Functions can be introduced by function declarations (9.1), method decla-

rations (10.1, 10.7), getter declarations (10.2), setter declarations (10.3), and

constructor declarations (10.6); and they can be introduced by function literals

(16.13).

Dart Programming Language Speciﬁcation 18

A function is asynchronous if its body is marked with the async or async* 

modiﬁer. Otherwise the function is synchronous. A function is a generator if 



its body is marked with the sync* or async* modiﬁer. Further details about

these concepts are given below.

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 generates 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, where one returns a

stream. Dart also allows both synchronous and asynchronous functions that produce

a single value.

Each declaration that introduces a function has a signature that speciﬁes

its return type, name, and formal parameter part, except that the return type

may be omitted, and getters never have a formal parameter part. Function

literals have a formal parameter part, but no return type and no name. The

formal parameter part optionally speciﬁes the formal type parameter list of the

function, and it always speciﬁes its formal parameter list. A function body is

either:

• a block statement (17.1) containing the statements (17) executed by the

function, optionally marked with one of the modiﬁers: async, async* or

sync*. Unless it is statically known that the body of the function cannot

complete normally (that is, it cannot reach the end and “fall through”,

cf. 17.0.1), it is a compile-time error if the addition of return; at the end

of the body would be a compile-time error. For instance, it is an error if

the return type of a synchronous function is int, and the body may complete

normally. The precise rules are given in section 17.12.

Because Dart supports dynamic function invocations, 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 function

body that ends without doing a throw or return will cause the function to

return the null object (16.4), as will a return without an expression. For

generator functions, the situation is more subtle. See further discussion in

section 17.12.

• of the form => e or the form async => e, which both return the value of

the expression e as if by a return e. The other modiﬁers do not apply here,

because they apply only to generators, discussed below. Generators are not

allowed to return a value, values are added to the generated stream or iterable

using yield or yield*. Let T be the declared return type of the function that

has this body. It is a compile-time error if one of the following conditions

hold:

– The function is synchronous, T is not void, and it would have been a

compile-time error to declare the function with the body { return e;

Dart Programming Language Speciﬁcation 19

} rather than => e. In particular, e can have any type when the return

type is void. This enables concise declarations of void functions. It

is reasonably easy to understand such a function, because the return

type is textually near to the returned expression e. In contrast, return

e; in a block body is only allowed for an e with one of a few speciﬁc

static types, because it is less likely that the developer understands

that the returned value will not be used (17.12).

– The function is asynchronous, ﬂatten(T ) is not void, and it would

have been a compile-time error to declare the function with the body

async { return e; } rather than async => e. In particular, e can

have any type when the ﬂattened return type is void, and the rationale

is similar to the synchronous case.

It is a compile-time error if an async, async* or sync* modiﬁer is attached

to the body of a setter or constructor.

An asynchronous setter would be of little use, since setters can only be used

in the context of an assignment (16.23), and an assignment expression always

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 its work.

An asynchronous constructor would, by deﬁnition, never return an instance

of the class it purports to construct, but instead return a future. Calling such

a beast via new would be very confusing. If you need to produce an object

asynchronously, use a method.

One could allow modiﬁers for factories. A factory for Future could be modi-

ﬁed by async, a factory for Stream could be modiﬁed by async* and a factory for

Iterable could be modiﬁed by sync*. No other scenario makes 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 general rule for

constructors in order to allow it.

It is a compile-time error if the declared return type of a function marked

async is not a supertype of Future<T> for some type T . It is a compile-time

error if the declared return type of a function marked sync* is not a supertype

of Iterable<T > for some type T . It is a compile-time error if the declared

return type of a function marked async* is not a supertype of Stream<T > for

some type T .

9.1 Function Declarations

functionDeclarations

A function declaration is a function that is neither a member of a class nor 

a function literal. Function declarations include exactly the following: library 

functions, which are function declarations at the top level of a library, and

local functions, which are function declarations declared inside other functions. 

Library functions are often referred to simply as top-level functions.

A function declaration consists of an identiﬁer indicating the function’s

name, possibly prefaced by a return type. The function name is followed by

Dart Programming Language Speciﬁcation 20

a signature and body. For getters, the signature is empty. The body is empty

for functions that are external.

The scope of a library function is the scope of the enclosing library. The

scope of a local function is described in section 17.4. In both cases, the name

of the function is in scope in its formal parameter scope (9.2).

It is a compile-time error to preface a function declaration with the built-in

identiﬁer static.

When we say that a function f

forwards to another function f

, we mean 

that invoking f

causes f

to be executed with the same arguments and/or

receiver as f

, and returns the result of executing f

to the caller of f

, unless f

throws an exception, in which case f

throws the same exception. Furthermore,

we only use the term for synthetic functions introduced by the speciﬁcation.

9.2 Formal Parameters

formalParameters

Every non-getter function declaration includes a formal parameter list, which 

consists of a list of required positional parameters (9.2.1), followed by any op-

tional parameters (9.2.2). The optional parameters may be speciﬁed either as a

set of named parameters or as a list of positional parameters, but not both.

Some function declarations include a formal type parameter list (9), in which 

case we say that it is a generic function. A non-generic function is a function 



which is not generic.

The formal parameter part of a function declaration consists of the formal 

type parameter list, if any, and the formal parameter list.

The following kinds of functions cannot be generic: Getters, setters, operators,

and constructors.

The formal type parameter list of a function declaration introduces a new

scope known as the function’s type parameter scope. The type parameter scope 

of a generic function f is enclosed in the scope where f is declared. Every formal

type parameter introduces a type into the type parameter scope.

If it exists, the type parameter scope of a function f is the current scope for

the signature of f , and for the formal type parameter list itself; otherwise the

scope where f is declared is the current scope for the signature of f.

This means that formal type parameters are in scope in the bounds of parameter

declarations, allowing for so-called F-bounded type parameters like

class C<X extends Comparable<X>> { ... },

and the formal type parameters are in scope for each other, allowing dependencies

like class D<X extends Y, Y> { ... }.

The formal parameter list of a function declaration introduces a new scope

known as the function’s formal parameter scope. The formal parameter scope 

of a non-generic function f is enclosed in the scope where f is declared. The

formal parameter scope of a generic function f is enclosed in the type parameter

scope of f. Every formal parameter introduces a local variable into the formal

parameter scope. The current scope for the function’s signature is the scope

that encloses the formal parameter scope.

剩余205页未读，继续阅读

wapeter

粉丝: 2
资源: 5

Dart语言规范2.2版：核心概念与特性解析

dart-sass-1.22.9-windows-x64.zip

dart grpc所需的dart-grpc-plugin dart-grpc-gen protoc，

dart-dart-dash

dart-app-PDF

rust-dart-test-源码.rar

tyrus-sample-echo-dart-1.6.zip

Dart-202.8346.zip

Dart-192.8052.zip

Dart-201.9317.zip

Dart-203.6912.zip

最新资源