TypeScript generation does not allow `null` for class/interface arguments

[Duncan Horn]

E.g. the following declaration:

void RaiseObjectEvent(TestObject value);

gets projected as:

public raiseObjectEvent(value: TestComponent.TestObject): void;

This should presumably be:

public raiseObjectEvent(value: TestComponent.TestObject | null): void;

It also needs to be considered whether null is allowed for strings (probably) and arrays (probably not). I'm also unsure if this needs to be applied to return types as well. Similarly, I can't remember if we allow/treat undefined in the same way that we treat null, so maybe we should allow both.

[nichamp]

The reason we didn't do this is because many APIs explicitly do not accept null instead of a valid object and would throw or worse nullptr-deref. I don't think this could be distinguished from winmds, so it is likely safer to not allow null by default in the generated .d.ts and require the developer, when they know it is safe, to either hand-edit the .d.ts or to do something like foo as any .

It would advise against accepting null for strings unless the underlying method is accepting winrt::Windows::Foundation::IReferencewinrt::hstring.

[Duncan Horn]

I'm not too keen on lying to prevent usage mistakes, particularly when some APIs accept/explicitly expect null in some situations, however I've since learned that TypeScript has the strictNullChecks option in the tsconfig.json, which can be set to false (IMO which should be the default behavior) and kind of makes this a moot point.