Usages of Partial accept primitives

[glazar]

TypeScript Version: 2.2

Code

interface ComponentState {
  a: string;
  b: number;
  c: boolean;
}

const setState = (state: Partial<ComponentState>) => {
   ....
}

setState(1)
setState("1")
setState(true)

Expected behavior:

Primitives should not be allowed to be passed in arguments.
Primitives should be excluded when using Partial.

The new object type, added with 2.2, can be used implicitly when using Partial construct without having to explicitly use it to have a workaround for this issue.

Actual behavior:

Usages of Partial accept primitives, even though the intent is that primitives be excluded.
Can explicitly also use the new object type, added with 2.2, to have a workaround for this issue.

[mhegazy]

Please see https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-all-types-assignable-to-empty-interfaces

[glazar]

@mhegazy
I understand why this happens - https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-all-types-assignable-to-empty-interfaces - when you manually create an interface which no members or with all optional members.

I strongly believe that the intent of Partial is to provide support for creating interfaces which all optional members while also enforcing that usages of it do not accept primitives.

The new object type can be used to cover the entire intent as mentioned in #14249.

[mhegazy]

#14249 talks about adding a constraint on the parameter of Partial, it says nothing about how the type is compared.

Mapped types are just a transformation, the generated type is just like any type you would write manually.. e.g. Patial<{ a: number, b:string}> === { a?: number, b?: string }.

[glazar]

@mhegazy
I just realized I made a mistake by referencing #14249. I now realise that the intent for that one was different, I just mistakenly read the code example. I was actually reading Partial<T> extends object instead of Partial<T extends object>.

I am just fine with using Partial as simply a mapped typed, just as a transformation, and then manually add the intent of always being an object. It is not a workaround but an explicit way of doing what I initially thought would be done implicitly.

Thanks for all the clarifications. They have helped me while having this issue discussed.

[mhegazy]

Issue #7485 better tracks the request. this is not unique to mapped types as i mentioned earlier. with an appropriate fix for #7485, your scenario should be flagged as an error too.