New behavior
No property existence check for object type.
let foo: object;
foo.bar; // no error
Rationale
The current object type is useful when used to type function arguments but not very useful on object members. See this IDL:
[SecureContext]
interface PaymentResponse {
[Default] object toJSON();
readonly attribute DOMString requestId;
readonly attribute DOMString methodName;
readonly attribute object details;
readonly attribute PaymentAddress? shippingAddress;
readonly attribute DOMString? shippingOption;
readonly attribute DOMString? payerName;
readonly attribute DOMString? payerEmail;
readonly attribute DOMString? payerPhone;
Promise<void> complete(optional PaymentComplete result = "unknown");
};
Here, the details member can be any "object" depending on payment method behavior. Current lib.d.ts defines this member as any so that a user can access any untyped members.
let response: PaymentResponse;
let { details } = response;
details.anImplementationDependentMemberName; // great
But any means it can be boolean, number, string or even null or undefined.
if (typeof details === "number") {
// `details` is resolved as `number` but really should be `never` here
}
details++; // no error, :(
A language service should be able to warn on these cases while still allowing arbitrary member accesses. Allowing such free accesses on object type will help here:
details.anImplementationDependentMemberName; // still great
if (typeof details === "number") {
// it cannot be a number, so `never` here
}
details++; // error now :D
Hey, a function can also be an object in TS!
Yes, but I don't think the fact will cause any problem as functions can also have arbitrary members. And I'm not proposing arbitrary function call.
New behavior
No property existence check for
objecttype.Rationale
The current
objecttype is useful when used to type function arguments but not very useful on object members. See this IDL:Here, the
detailsmember can be any "object" depending on payment method behavior. Current lib.d.ts defines this member asanyso that a user can access any untyped members.But
anymeans it can beboolean,number,stringor evennullorundefined.A language service should be able to warn on these cases while still allowing arbitrary member accesses. Allowing such free accesses on
objecttype will help here:Hey, a
functioncan also be anobjectin TS!Yes, but I don't think the fact will cause any problem as functions can also have arbitrary members. And I'm not proposing arbitrary function call.