Repository navigation
Possible bug: Hybrid between two interfaces of a union passes type checking #14383
Description
Activity
This is working as intended. The type
{ foo: string, baz: string }is indeed assignable to{ baz: string }because a subtype is free to add additional properties. The thing that is perhaps surprising is that you don't get an error in your example, but you do get an error in the following:const x: Baz = { foo: 'foo', // Error, excess property baz: 'foo', };
This is because when the target is a union type our excess property check for object literals (#3823) only checks that each property exists in some variant of the target. It should perhaps be stricter and check that the source is assignable to at least one variant with no excess properties (which would then error on your example).
Reacted by Jessica Franco, Sean Vieira and Justindsifford commented
on Mar 1, 2017 ContributorAuthorMore actionsAnders Hejlsberg (@ahejlsberg) Ah, okay that makes sense I suppose.
I'm admittedly ignorant as to how much added complexity it would take to add the stricter checking but, intuitively speaking, I would assume the example above to only compile successfully with interfaces having an index signature.
The use-case I had when I ran into this issue was when I was attempting to create a function parameter that accepted two different forms of authentication: One being basic username and password auth (in which case, both of these fields is required), and the other being browser cookie authentication where only a single field is required.
I ended up just creating a union between a
BasicAuthinterface andstringwhich solved the problem.Thanks for the education on this.
- addedWorking as IntendedThe behavior described is the intended behavior; this is not a bugThe behavior described is the intended behavior; this is not a bug
on Mar 1, 2017 I'd love to see these stricter checks at some point - any way to work around this issue without changing the types themselves? I'm trying to validate some existing data, and I can describe all the types I need, but the lack of the stricter check lets bad data through.
// no error - this is what I hoped would work let x: { a: number; } | { b: number; } = { a: 5, b: 5 }; // errors as expected x = { a: 5 }; x.b = 4; // errors as expected const y: { b: number; } = { a: 5, b: 5 };Reacted by JustinRyanCavanaugh commented
on Mar 7, 2017 MemberMore actionsSome relevant discussion of this at #12936 (comment)
- marked this as a duplicate of Interface unions type checking #17256
on Jul 18, 2017 - locked and limited conversation to collaborators
on Jun 19, 2018
TypeScript Version: 2.1.1 / nightly (2.2.0-dev.20170228)
Went to StackOverflow with this first and the consensus there seems to be that this is a bug.
Here's my question again for convenience:
Consider a situation where an object can have exactly the
FooBarorBazinterface listed below.It's my understanding that this "one or the other" situation can be handled by creating a union between
FooBarandBaz.So far so good...
The issue I'm having is that the following object passes type checking:
Expected behavior:
xshould not pass type checking. It's neitherFooBarnorBaz, but rather a combination between the two.Actual behavior:
xpasses type checking.Playground Example