async function return type checking is too strict

[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.

[mhegazy]

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.

[yortus]

Sorry @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.