Adjust the function literal return type inference section to handle "weird" types

resources/type-system/inference.md

@@ -6,6 +6,12 @@ Status: Draft
 
 ## CHANGELOG
 
+2026.03.31
+  - Change the function literal return type inference rules to handle
+    generator return types which are not of the form `Iterable<...>` or
+    `Stream<...>`. To do this, the definition of the imposed return type
+    schema was moved to a separate section.
+
 2024.12.17
   - Change the function literal return type inference rules to ignore
     `return;` statements in generators (it doesn't actually cause null to be
@@ -104,7 +110,7 @@ and which this proposal is designed to satisfy:
   violates this principle.
 * The inference for local variables, top-level variables, and fields, should
   either agree or error out.  The same expression should not be inferred
-  differently at different syntactic positions.  It’s ok for an expression to be
+  differently at different syntactic positions.  It's ok for an expression to be
   inferrable at one level but not at another.
 * Obvious types should be inferred.
 * Inferred and annotated types should be treated the same.
@@ -260,62 +266,103 @@ Note that `late` fields are inferred exactly as non-`late` fields.  However,
 unlike normal fields, the initializer for a `late` field may reference `this`.
 
 
-## Function literal return type inference.
+## The imposed return type schema
 
-Function literals which are inferred in an empty typing context (see below) are
-inferred using the declared type for all of their parameters.  If a parameter
-has no declared type, it is treated as if it was declared with type `dynamic`.
-Inference for each returned expression in the body of the function literal is
-done in an empty typing context (see below).
+*This section assumes that Dart has null safety (older versions of the
+language are ignored).*
 
-Function literals which are inferred in an non-empty typing context where the
-context type is a function type are inferred as described below.
+In the following we refer to the asynchronous or synchronous element type
+schema of a type. This is defined from the asynchronous respectively
+synchronous element type of a type by treating `_` as a type.
 
-Each parameter is assumed to have its declared type if present.  If no type is
-declared for a parameter and there is a corresponding parameter in the context
-type schema with type schema `K`, the parameter is given an inferred type `T`
-where `T` is derived from `K` as follows.  If the greatest closure of `K` is `S`
-and `S` is a subtype of `Null`, then without null safety `T` is `dynamic`, and
-with null safety `T` is `Object?`. Otherwise, `T` is `S`. If there is no
-corresponding parameter in the context type schema, the variable is treated as
-having type `dynamic`.
+Assume that _D_ is a top-level, static, or instance declaration of a
+synchronous non-generator function, method, getter, setter, or constructor;
+or it is a local synchronous non-generator function declaration; assume
+that the return type of _D_ is `R`. If `R` is `dynamic`, the _imposed
+return type schema_ of _D_ is `_`.  Otherwise, the imposed return type
+schema of _D_ is `R`.
 
-The return type of the context function type is used at several points during
-inference.  We refer to this type as the **imposed return type
-schema**. Inference for each returned or yielded expression in the body of the
-function literal is done using a context type derived from the imposed return
-type schema `S` as follows:
-  - If the function expression is neither `async` nor a generator, then the
-    context type is `S`.
-  - If the function expression is declared `async*` and `S` is of the form
-    `Stream<S1>` for some `S1`, then the context type is `S1`.
-  - If the function expression is declared `sync*` and `S` is of the form
-    `Iterable<S1>` for some `S1`, then the context type is `S1`.
-  - Otherwise, without null safety, the context type is `FutureOr<flatten(T)>`
-    where `T` is the imposed return type schema; with null safety, the context
-    type is `FutureOr<futureValueTypeSchema(S)>`.
+Assume that _D_ is a top-level, static, or instance declaration of an
+asynchronous non-generator function, method, or getter; or it is a local
+asynchronous non-generator function declaration; assume that the return
+type of _D_ is `R`. The imposed return type schema of _D_ is
+`FutureOr<futureValueTypeSchema(S)>`.
 
 The function **futureValueTypeSchema** is defined as follows:
 
 - **futureValueTypeSchema**(`S?`) = **futureValueTypeSchema**(`S`), for all `S`.
-- **futureValueTypeSchema**(`S*`) = **futureValueTypeSchema**(`S`), for all `S`.
-- **futureValueTypeSchema**(`Future<S>`) = `S`, for all `S`.
-- **futureValueTypeSchema**(`FutureOr<S>`) = `S`, for all `S`.
+- **futureValueTypeSchema**(`Future<S>`) = **eraseDynamic**(`S`), for all `S`.
+- **futureValueTypeSchema**(`FutureOr<S>`) = **eraseDynamic**(`S`), for all `S`.
 - **futureValueTypeSchema**(`void`) = `void`.
-- **futureValueTypeSchema**(`dynamic`) = `dynamic`.
+- **futureValueTypeSchema**(`dynamic`) = **eraseDynamic**(`dynamic`).
 - **futureValueTypeSchema**(`_`) = `_`.
 - Otherwise, for all `S`, **futureValueTypeSchema**(`S`) = `Object?`.
 
 _Note that it is a compile-time error unless the return type of an asynchronous
 non-generator function is a supertype of `Future<Never>`, which means that
 the last case will only be applied when `S` is `Object` or a top type._
 
+The helper function **eraseDynamic** is defined as follows:
+
+- **eraseDynamic**(`dynamic`) = `_`.
+- Otherwise, for all `S`, **eraseDynamic**(`S`) = `S`.
+
+Assume that _D_ is a top-level, static, or instance declaration of a
+synchronous respectively asynchronous generator function, method, or
+getter; or it is a local synchronous respectively asynchronous generator
+function declaration; assume that the return type of _D_ is `R`.
+
+Let `S` be the synchronous respectively asynchronous element type of `R`.
+If `S` is `dynamic`, the imposed return type schema of _D_ is `_`.
+Otherwise, the imposed return type schema of _D_ is `S`.
+
+Assume that _D_ is a non-generator function literal which is being inferred
+with context type schema `T`.
+
+If `T` is not a function type schema, or `T` is a function type schema with
+return type `dynamic`, the imposed return type schema of _D_ is `_`.
+Otherwise, let `S` be the return type schema of `T`. *Note that `S` may
+contain references to type variables declared by _D_ itself, which is not a
+problem.* In this case the imposed return type schema of _D_ is `S`.
+
+Any imposed return type schema can be designated as the _imposed return
+type_ in a situation where it is a type.
+
+
+## Function literal return type inference
+
+Function literals which are inferred in an empty typing context (see below)
+are inferred using the declared type for all of their parameters.  If a
+parameter has no declared type, it is treated as if it was declared with
+type `dynamic`.  Inference for each returned or yielded expression in the
+body of the function literal is done in an empty typing context (see
+below).
+
+Function literals which are inferred in a non-empty typing context where the
+context type is not a function type are inferred in the empty typing context.
+
+Function literals which are inferred in an non-empty typing context where the
+context type is a function type are inferred as described below.
+
+Each parameter is assumed to have its declared type if present.  If no type is
+declared for a parameter and there is a corresponding parameter in the context
+type schema with type schema `K`, the parameter is given an inferred type `T`
+where `T` is derived from `K` as follows.  If the greatest closure of `K` is `S`
+and `S` is a subtype of `Null`, then without null safety `T` is `dynamic`, and
+with null safety `T` is `Object?`. Otherwise, `T` is `S`. If there is no
+corresponding parameter in the context type schema, the variable is treated as
+having type `dynamic`.
+
+Inference for each returned or yielded expression in the body of the
+function literal is done using the imposed return type schema of the
+function literal.
+
 In order to infer the return type of a function literal, we first infer the
 **actual returned type** of the function literal.
 
 The actual returned type of a function literal with an expression body is the
 inferred type of the expression body, using the local type inference algorithm
-described below with a typing context as computed above.
+described below with a context type schema `K` as computed above.
 
 The actual returned type of a function literal with a block body is computed as
 follows.  Let `T` be `Never` if every control path through the block exits the
@@ -353,8 +400,8 @@ body.
 The **actual returned type** of the function literal is the value of `T` after
 all `return` and `yield` statements in the block body have been considered.
 
-Let `T` be the **actual returned type** of a function literal as computed above.
-Let `R` be the greatest closure of the typing context `K` as computed above.
+Let `T` be the **actual returned type** of a function literal as computed
+above.  Let `R` be the greatest closure of the context type schema `K`.
 
 With null safety: if `R` is `void`, or the function literal is marked `async`
 and `R` is `FutureOr<void>`, let `S` be `void` (without null-safety: no special

specification/dartLangSpec.tex

@@ -40,6 +40,10 @@
 % - Remove the getter/setter signature mismatch error. It is no longer required
 %   that the getter return type and setter parameter type are related in any way.
 %
+% Mar 2026
+% - Define the (a)synchronous element type of a type (so we can use that
+%   concept in feature specifications).
+%
 % Jan 2026
 % - Specify that collection elements are allowed to have type `void` in a
 %   collection literal where the corresponding actual type argument is `void`.
@@ -2172,27 +2176,44 @@ \section{Functions}
 }
 
 \LMHash{}%
-We define the
-\IndexCustom{element type of a generator function}{%
-    function!generator!element type}
-$f$ as follows:
-%
-Let $S$ be the union-free type derived from the declared return type of $f$.
+We define two variants of the element type of a type $T$:
+Let $S$ be the union-free type derived from $T$.
 %
-If $f$ is a synchronous generator and
-$S$ implements \code{Iterable<$U$>} for some $U$
+If $S$ implements \code{Iterable<$U$>} for some $U$
 (\ref{interfaceSuperinterfaces})
-then the element type of $f$ is $U$.
+then the
+\IndexCustom{synchronous element type}{%
+  type!synchronous element type}
+of $T$ is $U$.
+Similarly, if $S$ implements \code{Stream<$U$>} for some $U$
+then the
+\IndexCustom{asynchronous element type}{%
+  type!asynchronous element type}
+of $T$ is $U$.
 %
-If $f$ is an asynchronous generator and
-$S$ implements \code{Stream<$U$>} for some $U$
+Otherwise, if $S$ is a supertype of \code{Object}
+\commentary{(which includes \code{Object} itself)}
+then the synchronous as well as the asynchronous
+element type of $T$ is \DYNAMIC.
+Otherwise, both kinds of element type is undefined.
+
+\LMHash{}%
+The
+\IndexCustom{element type of a generator function}{%
+  function!generator!element type}
+$f$ is defined as follows:
+%
+If $f$ is a synchronous generator function with return type $T$, 
+and the synchronous element type of $T$ is $U$,
 then the element type of $f$ is $U$.
 %
-Otherwise, if $f$ is a generator (synchronous or asynchronous)
-and $S$ is a supertype of \code{Object}
-\commentary{(which includes \code{Object} itself)}
-then the element type of $f$ is \DYNAMIC.
-\commentary{No further cases are possible.}
+Similarly, if $f$ is an asynchronous generator function with return type $T$,
+and the asynchronous element type of $T$ is $U$,
+then the element type of $f$ is $U$.
+\commentary{%
+  The element type of a generator function declaration which is not
+  a compile-time error is always defined.%
+}
 
 
 \subsection{Function Declarations}