This document may be obsolete, or it may be a proposed new version; if in doubt please consider the version in the SDK repository (which may not yet exist).
Author: eernst@.
Version: 0.2 (2018-09-04)
Status: Under discussion.
This document is a Dart 2 feature specification of the static typing
of instance members of a receiver whose static type is dynamic.
This document uses discussions in this github issue as a starting point.
For Dart programs using a statically typed style, it is often helpful to
use the most precise static type for an expression which is still sound.
In contrast, if such an expression gets type dynamic it often causes
subsequent type computations such as inference to make less useful
decisions, or it may mask errors which are likely or guaranteed to occur at
run time. Here is an example:
class A {
String toString([bool b = true]) =>
b ? 'This is an A!' : 'Whatever';
}
foo(List<String> xs) {
for (String s in xs) print(s);
}
main() {
dynamic d = new A();
var xs = [d.toString()];
foo(xs);
}In this example, the actual type argument passed to the list literal
[d.toString()] by inference depends on the static type of the expression
d.toString(). If that expression is given the type dynamic (as it would
be in Dart 1) then the resulting list will be a List<dynamic>, and hence
the invocation of foo would fail because it requires an argument of type
List<String>.
In general, a receiver with static type dynamic is assumed to have all
members, i.e., we can make the attempt to invoke a getter, setter, method,
or operator with any name, and we can pass any list of actual arguments and
possibly some type arguments, and that will not cause any compile-time
errors. Various checks may be performed at run time when such an invocation
takes place, and that is the whole point: Usage of expressions of type
dynamic allows developers to skip the static checks and instead have
dynamic checks.
However, every object in a Dart program execution has a type which is a
subtype of Object. Hence, for each member declared by Object, it will
either inherit an implementation declared by Object, or it will have some
implementation specified as an override for the declaration in
Object. Given that overriding declarations must satisfy certain
constraints, we do know something about the properties of a member declared
in Object. This allows static analysis to give static types to some
expressions which are more precise than dynamic, even for a member access
where the receiver has type dynamic, and that is the topic of this
document.
We will obey the general principle that an instance method invocation
(including getters, setters, and operators) which would be compiled without
errors under some typing of the receiver must also be without compile-time
errors when the receiver has type dynamic. It should be noted that there
is no requirement that the typing relies only on declarations which are in
scope at the point where the invocation occurs, it must instead be possible
to declare such a class that the invocation can be statically typed. The
point in obeying this principle is that dynamic invocation should be
capable of performing every invocation which is possible using types.
For instance, d.toString(42) cannot have a compile-time error when d
has static type dynamic, because we could have the following declaration,
and d could have had type D:
class D {
noSuchMethod(Object o) => o;
Null toString([int i]) => null;
}Similarly, d.noSuchMethod('Oh!') would not be a compile-time error,
because a contravariant type annotation on the parameter as shown above
would allow actual arguments of other types than Invocation.
On the other hand, it is safe to assign the static type String to
d.toString(), because that invocation will definitely invoke the
implementation of toString in Object or an override thereof, and that
override must have a return type which is String or a subtype (for
String that can only be Null, but in general it can be any subtype).
It may look like a highly marginal corner of the language to give special
treatment to the few methods declared in Object, but it does matter in
practice that a number of invocations of toString are given the type
String. Other members like hashCode get the same treatment in order to
have a certain amount of consistency.
Moreover, we have considered generalizing the notion of "the type dynamic"
such that it becomes "the type dynamic based on T" for any given type
T, using some syntax, e.g., dynamic(T). The idea would be that
statically known methods invoked on a receiver of type dynamic(T) would
receive static checking, but invocations of other methods get dynamic
checking. With that, the treatment specified in this document (which was
originally motivated by the typing of toString) will suddenly apply to
any member declared by T, where T can be any type (that is, any
declarable member). It is then important to have a systematic approach and
a simple conceptual "story" about how it works, and why it works like
that. This document should be a usable starting point for such an approach
and story.
In this section, Object denotes the built-in class Object, and
dynamic denotes the built-in type dynamic.
In the following, we specify the static type of certain expressions of a
specific syntactic form. In the situation where an expression e is
of the form d.m(arguments) or d.m<typeArguments>(arguments) where
d is a primary, m is an identifier, arguments is an actual argument
list, and typeArguments is a list of actual type arguments, the
applicable case is one that includes all of e, not just the property
extraction part of e, that is, not just d.m.
Let e be an expression of the form d.m where the static type of d is
dynamic and m is a getter declared in Object; if the return type of
Object.m is T then the static type of e is T.
For instance, d.hashCode has type int and d.runtimeType has type
Type.
Let e be an expression of the form d.m where the static type of d is
dynamic and m is a method declared in Object whose method signature
has type F (which is a function type). The static type of e is then
F.
For instance, d.toString has type String Function().
Let e be an expression of the form d.m(arguments) or
d.m<typeArguments>(arguments) where the static type of d is dynamic,
m is a getter declared in Object with return type F, arguments is
an actual argument list, and typeArguments is a list of actual type
arguments, if present. Static analysis will then process e as a function
expression invocation where a function of static type F is applied to the
given argument part.
So d.runtimeType(42) is a compile-time error, because it is checked as a
function expression invocation where an entity of static type Type is
invoked. Note that it could actually succeed: An overriding implementation
of runtimeType could return an instance whose dynamic type is a subtype
of Type that has a call method. We decided to make it an error because
it is likely to be a mistake, especially in cases like d.hashCode() where
a developer might have forgotten that hashCode is a getter.
Let e be an expression of the form d.m(arguments) where the static type
of d is dynamic, arguments is an actual argument list, and m is a
method declared in Object whose method signature has type F. If the
number of positional actual arguments in arguments is less than the
number of required positional arguments of F or greater than the number
of positional arguments in F, or if arguments includes any named
arguments with a name that is not declared in F, the type of e is
dynamic. Otherwise, the type of e is the return type in F.
So d.toString(bazzle: 42) has type dynamic whereas d.toString() has
type String. Note that invocations which "do not fit" the statically
known declaration are not errors, they just get return type dynamic.
Let e be an expression of the form d.m<typeArguments>(arguments) where
the static type of d is dynamic, typeArguments is a list of actual
type arguments, arguments is an actual argument list. It is a
compile-time error if m is a non-generic method declared in Object.
No generic methods are declared in Object. Hence, we do not specify that
there must be the statically required number of actual type arguments, and
they must satisfy the bounds. That would otherwise be the consistent
approach, because the invocation is guaranteed to fail when any of those
requirements are violated, but generalizations of this mechanism would need
to include such rules.
For an instance method invocation e (including invocations of getters,
setters, and operators) where the receiver has static type dynamic and
e does not match any of the above cases, the static type of e is
dynamic.
When a cascadeSection performs a getter or method invocation that
corresponds to one of the cases above, the corresponding static analysis
and compile-time errors apply.
For instance, d..foobar(16)..hashCode() is an error.
Note that only very few forms of instance method invocation with a
receiver of type dynamic can be a compile-time error. Of course,
some expressions like x[1, 2] are syntax errors even though they
could also be considered "invocations", and subexpressions are checked
separately so any given actual argument could be a compile-time
error. But almost any given argument list shape could be handled via
noSuchMethod, and an argument of any type could be accepted because any
formal parameter in an overriding declaration could have its type
annotation contravariantly changed to Object. So it is a natural
consequence of the principle mentioned in 'Motivation' that a dynamic
receiver admits almost all instance method invocations. The few cases where
an instance method invocation with a receiver of type dynamic is an error
are either guaranteed to fail at run time, or they are very likely to be
developer mistakes.
This feature has no implications for the dynamic semantics, beyond the ones which are derived directly from the static typing.
For instance, a list literal may have a run-time type which is determined via inference by the static type of its elements, as in the example in the 'Motivation' section, or the actual type argument may be influenced by the typing context, which may again depend on the rules specified in this document.
-
0.2 (2018-09-04) Adjustment to make
d.hashCode()and similar expressions an error, cf. this github issue. -
0.1 (2018-03-13) Initial version, based on discussions in this github issue.