Type 'unknown' should no be assignable to type '{}'

[feeddageek]

Typescript no longer preventing assignation of unknown to {} without strictNullChecks

TypeScript Version: from 3.5.3 to 3.7.5
Work as expect from 3.0.3 to 3.4.5

Search Terms: unknown assignable {} empty type

Code

    let a: unknown;
    const b: {} = a;
    const c: object = a;

Expected behavior:

    let a: unknown;
    const b: {} = a;// Type 'unknown' is not assignable to type '{}'.
    const c: object = a;// Type 'unknown' is not assignable to type 'object'

Actual behavior:

    let a: unknown;
    const b: {} = a;// No error for this line
    const c: object = a;// Type 'unknown' is not assignable to type 'object'

Playground Link:
3.3.3 strictNullChecks=true Error as expected
3.3.3 strictNullChecks=false Error as expected
3.7.5 strictNullChecks=true Error as expected
3.7.5 strictNullChecks=false Missing error
Related Issues:
#26796

[DanielRosenwasser]

If strictNullChecks is off, {} is implicitly {} | null | undefined, which encompasses the same set of values as unknown. I'm not totally clear on why that should change.

Thoughts @ahejlsberg?

[feeddageek]

If strictNullChecks is off, {} is implicitly {} | null | undefined, which encompasses the same set of values as unknown. I'm not totally clear on why that should change.

Does it ?
3.0 change-log specifically state :

// unknown assignable only to itself and any
let v6: {} = x; // Error
let v7: {} | null | undefined = x; // Error

There is nothing specifying that it's only true with strictNullChecks (and no other change-log between 3.0 and 3.7 defines this change in expected behavior)

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[feeddageek]

@RyanCavanaugh It is not working as intended. There has been an undocumented change in behaviour between 3.3 and 3.4. Even if it was intended (or a desirable accident) and it doesn't need fixing, it need to be documented.

The 3.0 changlog clearly state that this assignation should not be permitted and I can't find any indication that it should have changed.