Inconsistent behavior between assignment and "as" with object literals after enums unification

[jakebailey]

Bug Report

🔎 Search Terms

Conversion may be a mistake enum unification object literal as

🕗 Version & Regression Information

• This is a crash
• This changed between versions 4.9 and 5.0

⏯ Playground Link

Playground link with relevant code

💻 Code

enum Foo {
    None = +0,
    A = 1,
    B = 2,
    C = 4,
}

interface UsesFoo {
    foo: Foo;
}


const x = { 
    foo: 7
} as UsesFoo;

const y: UsesFoo = { 
    foo: 7
};

🙁 Actual behavior

There's an error on the first assignment and no error on the second assignment.

🙂 Expected behavior

Probably, no errors on either? Or something consistent?

This is a method suggested by https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/#union-enums-cannot-be-compared-to-arbitrary-numbers (and I minimized this from OWA).

[ahejlsberg]

The thing that has changed here is that all enums are now unions of their members, where previously that would only be the case when member initializers were simple literals (without a leading +). The error in the example isn't new, it happens in previous versions when Foo is a union enum:

enum Foo {
    None = 0,  // Removing the '+' causes Foo to be a union enum and the 'as' error to appear
    A = 1,
    B = 2,
    C = 4,
}

The reason for the error in the assignment to x is that foo is given the literal type 7 whereas in the assignment to y is is widened to type number (EDIT: Actually, no, it's an inconsistency between assignability and comparability). We may want to change something there, but that'll have wider ranging consequences no doubt.

[ahejlsberg]

Well, it comes down to this:

enum Foo {
    None = 0,
    A = 1,
    B = 2,
    C = 4,
}

function qq(x: Foo, y: 7) {
    if (x === y) {}  // Error, not comparable
    x = y;  // But, oddly, assignable
}

Assignability should definitely imply comparability, so something's off here. But, again, doesn't really have anything to do with the enum unification changes.

[jakebailey]

I pulled this example from the OWA codebase; given that enums are now always unions and there is no escape hatch to say "treat me like a number", it seems like this is as designed. It's just a change I noted when perf testing OWA against 5.0 and didn't want to forget.

The inconsistency I think we saw during the design meeting so it's somewhat known. It's just awkward that these seemingly very similar code snippets behave differently, of course.

Of course, it's a shame that the (pretty recent) blog post implies support for the pattern of "number, with a few well-known values" and now there doesn't seem to be a way to do that. But, I suppose we already don't really let you do that with string unions either.

[ahejlsberg]

@jakebailey Which blog post was that?

It's actually still possible to declare a "unique number type with a few well-known values" using the following pattern:

enum E {}
namespace E {
    export const Foo = 1 as E;
    export const Bar = 2 as E;
}
let foo = E.Foo;  // type E, value 1
let bar = E.Bar;  // type E, value 2

This is because enum E {} still declares a unique subtype of number, E, with no named values. In the new "enums are always unions of the declared members" world view, an empty enum declaration ought to have type never, but for backwards compatibility reasons we still create a unique enum type.

[jakebailey]

Which blog post was that?

It's linked in the issue, but: https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/#union-enums-cannot-be-compared-to-arbitrary-numbers

[frank-dspeed]

isnt replacing enum by const the right thing to do as we all as typescript community want to deprecate enum in favor of tc39 annotations

i would label this wontfix and advice to switch to const

enum Foo {
    None = 0,  // Removing the '+' causes Foo to be a union enum and the 'as' error to appear
    A = 1,
    B = 2,
    C = 4,
}

background all none ECMAScript compatible features should get avoided thats why the issue template on Porposals asks if it is a change for JS parsing.