type guard on (string & string literal) doesn't imply type guard on (string literal)

[willportnoy]

TypeScript Version: 2.1.6

Code

// A *self-contained* demonstration of the problem follows...
interface Base {
    readonly name: string;
}

interface DerivedA extends Base {
    readonly name: 'DerivedA',
    readonly A: string;
}

interface DerivedB extends Base {
    readonly name: 'DerivedB',
    readonly B: string;
}

type Derived = DerivedA | DerivedB;

type Both = Base & Derived;

// this function seems sufficient to hide the type from the compiler
function make(): Both {
    return {
        name: 'DerivedB',
        B: 'b',
    };
}

const derived = make();

// var name: (string & "DerivedB") | (string & "DerivedA")
if (derived.name === 'DerivedB') {
    // Property 'B" does not exist on type 'Both'
    console.log(derived.B);
}

Expected behavior:

I expect the type guard (derived.name === 'DerivedB') to narrow the type of derived from (Base & DerivedA) | (Base & DerivedB) to Base & DerivedB or DerivedB.

Actual behavior:

In the if block, derived.B is not available.

[mhegazy]

string & "DerivedA" is the same as string. Ultimately, (string & "DerivedB") | (string & "DerivedA") is just string.

I am not sure I see the reason intersection types is used in this scenario. DerivedB is a Base regardless, so your function make should just return DerivedB.

[willportnoy]

make returns DerivedB because it's sufficient for a minimal reproduction.

I'm trying to leverage the discriminated unions feature described within the Advanced Types.

Normally, this type guard works fine (for example if make returned Derived). But because the redundant Base type is mixed in, the type guard does not properly discover the flow-based type. I believe it's redundant because a "string literal" type implies "string", and therefore the "string" is redundant and only seems to interfere with the flow-based typing.

In my actual application, Base is used at a lower layer to signal the presence of a type discriminator field. Derived is used at a higher layer to leverage the "discriminated unions" feature.

[mhegazy]

I believe it's redundant because a "string literal" type implies "string", and therefore the "string" is redundant and only seems to interfere with the flow-based typing.

That is correct, but the opposite is not true. string & "literal" is not "literal", it is string.

Can you share more context about your original issue?

[gcnew]

I might be missing something, but why is string & "literal" simply string? I think it should be "literal". On the other hand string | "literal" can be simplified to just string.

[willportnoy]

Mohamed Hegazy (@mhegazy) I have mostly the same question as Marin Marinov (@gcnew) too.

In particular, I want https://en.wikipedia.org/wiki/Conjunction_elimination to apply so that TypeScript can use the "string literal" type so that I can use flow-based typing for discriminated unions. Since any "string literal" is a more specific derived type of "string", one option is simplify the intersection type to the more restrictive "string literal" type.

[gcnew]

I don't think this issue should be closed. It asks for a logical improvement, which might not be of the top-most priority, but is still a good suggestion.

A negative of closing is that closed tickets are very hard to find.

Another sibling: #12289

[weswigham]

The example in the OP works noadays~