Skip to content

async function return type checking is too strict #6027

Closed

Description

@yortus
// Three functions and their return types
function ordinaryFunction() { return 42; }      // returns number
function* generatorFunction() { yield 42; }     // returns IterableIterator<number>
async function asyncFunction() { return 42; }   // returns Promise<number>

// Assign result to compatible interface type - behaviour is consistent
var o1: number = ordinaryFunction();                     // OK
var o2: any = ordinaryFunction();                        // OK
var g1: Iterable<number> = generatorFunction();          // OK
var g2: any = generatorFunction();                       // OK
var a1: PromiseLike<number> = asyncFunction();           // OK
var a2: any = asyncFunction();                           // OK

// Annotate result with compatible interface type - behaviour is inconsistent
function of1(): number { return 42; }                    // OK
function of2(): any { return 42; }                       // OK
function* gf1(): Iterable<number> { yield 42; }          // OK
function* gf2(): any { yield 42; }                       // OK
async function af1(): PromiseLike<number> { return 42; } // ERROR
async function af2(): any { return 42; }                 // ERROR

This behaviour seems to be by design but the inconsistency is annoying. There is no 'in principle' justification for different treatment of the last two examples.

This has been discussed on #5911 but the consensus there on fixing the bug seems like it might involve just changing the error message text.

I think it should be possible to make the last two examples work consistently like the rest without affecting the special type-directed emit behaviour of async function return type annotations, along the lines suggested here and here. It would involve a non-breaking relaxation of the current over-strict behaviour.

Activity

  1. mhegazy commented on Dec 10, 2015

    @mhegazy
    Contributor

    I would appreciate it if you can keep the discussion to one issue in the future.

    As discussed in #5911, this matches the design. There are already two other issues on this topic where we have discussed the design, so le's keep it there.

  2. yortus commented on Dec 10, 2015

    @yortus
    ContributorAuthor

    Sorry Mohamed Hegazy (@mhegazy) it must look like I'm trolling but that's not my intention. I genuinely thought the issue described here was not being considered in #5911 as per the comments here and here. I would just like this specific issue to receive due consideration. If that can go on in #5911 then that's fine.

  3. locked and limited conversation to collaborators on Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    By DesignDeprecated - use "Working as Intended" or "Design Limitation" instead

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions