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

I think you mean FutureOr<futureValueTypeSchema(R)>.

Why not save the reader the trouble of evaluating eraseDynamic(dynamic) and just say this?

• futureValueTypeSchema(dynamic) = _.

Why make this change?

If it makes any difference whether the future-value-type-schema is _ or dynamic, then actually writing dynamic as the return type may suggest that the user wanted the dynamic type.

I don't see any definition of imposed return type schema for a generator function literal. I've addressed this in my comment on line 310.

The paragraph above doesn't say anything about asynchronous vs synchronous, so I'm assuming that this paragraph is intended to apply to both asynchronous and synchronous non-generator function literals. In the case of asynchronous non-generator function literals, shouldn't the imposed return type schema be FutureOr<futureValueTypeSchema(S)>?

I've addressed this in my comment on line 310.

Two concerns here:

• The definition of synchronous/asynchronous element type behaves differently depending on whether the type in question is a supertype of Object. When extending this definition to schemas, should we treat _ as a type that extends Object or a type that doesn't extend Object?
• Synchronous/asynchronous element type of T is undefined in the case where T neither implements Iterable<S> (respectively Stream<S>) for some S, nor is a supertype of Object. In your edit to the spec, when you use asynchronous/synchronous element type to define element type of a generator function, you've explained that the undefined case only occurs if there's a compile-time error. But I believe that during type inference of a function literal, that undefined case is possible to reach (because there are situations where it's ok for the static type of an expression to fail to satisfy the expression's schema). So we need to define how we handle that case.

The order is a bit confusing here, because we've interrupted the list of cases that define imposed return type schema in order to define futureValueTypeSchema and eraseDynamic, and now we're returning to add more cases to imposed return type schema. I'd recommend defining each term in its own section, with bullets for cases, e.g.:

Assume that D is a top-level, static, or instance declaration of a function, method, getter, setter, or constructor; or it is a local function declaration or a function literal. Then the imposed return type schema of D is defined as follows:

• Define R as follows:
  • If D is a function literal which is being inferred with context type schema T:
    • If T is a function type schema, let R be the return type of T.
    • Otherwise let R be _.
  • Otherwise, let R be the return type of D. Note that R may contain references to type variables declared by D itself, which is not a problem.
• If D is a synchronous non-generator, the imposed return type schema of D is eraseDynamic(R).
• If D is an asynchronous non-generator, the imposed return type schema of D is FutureOr<futureValueTypeSchema(R)>.
• If D is a synchronous generator, the imposed return type schema of D is eraseDynamic(S), where S is the synchronous element type of R.
• If D is an asynchronous generator, the imposed return type schema of D is eraseDynamic(S), where S is the asynchronous element type of R.

The function futureValueTypeSchema is defined as follows:

...

The helper function eraseDynamic is defined as follows:

...

(Also shows the incongruence going from "synchronous element type", which is very precise and understandable, to "imposed return type", which has nothing to do with returns.)

That's no longer necessary to say. Those older versions are no longer supported at all.

(What's the difference between a "function" and a "method"?)

I would use a different name for different kinds of functions.
Instead of "imposed return type scheme", I'd have "return type" for a sync-non-generator, "future value type" for an async-non-generator, "iterable element type" for a sync-generator and "stream element type" for an async-generator.

Then refer to the relevant one at return or yield[*] statements.

That reduces the risk of accidentally mixing up things, or assuming something locally that isn't true globally.
And it avoids calling the yield-type a "return type", which it most certianly isn't.
(It's derived from a return type, but it's an element type.)

Which means this section isn't necessary.
At a return statement, "if the current function is not an async function, the context type is the return type. if the current function is an async function, the context type is FutureOr<T> where T is the future value type of the return type of the current function."

Similarly for yields.

Why make this change?

If it makes any difference whether the future-value-type-schema is _ or dynamic, then actually writing dynamic as the return type may suggest that the user wanted the dynamic type.

(Also shows the incongruence going from "synchronous element type", which is very precise and understandable, to "imposed return type", which has nothing to do with returns.)

Why is that not just eraseDynamic(S)?

Can be ... will it? And what if it isn't?

"if present" -> "if it has a declared type". It's not clear whether it's the declared type or the parameter which must be present.

What if the function is generic, is that covered?