Change return type of Object call signature to unknown (currently any)

[szacskesz]

🔎 Search Terms

ObjectConstructor, Object, assignable, function

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about 5.3.3

⏯ Playground Link

https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEAzArgOzAFwJYHtVJxwAowAjALniIEp4BeAPngGcMYtUBzaygNxyzAA3ACgRiQjSEB6afECg5PACiADwAO4DCGDw4zZBAyUQMGDhjjJNekwBEt6jLmLVGzNt0h9hyqhzwTMwsJYmtGeFQDCEdZBWV1TQ89AyMA03NLYgBvAF9qWJcE9x1knzSgzKIAZTYObic410SSrxTff0CMkKIAOWQAW1ITGOd4ty0W71TOi0qAeVIAK00R+EAZcjHmzynjdIsgA

💻 Code

declare function foo(cb: () => string): void;

foo();// ✅ Expected result: error
foo(() => "");// ✅ Expected result: no error
foo(() => null);// ✅ Expected result: error
foo({})// ✅ Expected result: error
foo(String);// ✅ Expected result: no error
foo(Number);// ✅ Expected result: error

foo(Object);// ❌ Expected result: error

🙁 Actual behavior

Object (ObjectContructor) is assignable to any function, because it has a callable signature with return type of any.

This lets the developers to use Object where only a properly typed function would be allowed, which can lead to unexpected runtime errors.

I know this is a pretty edge case, but in my opinion it's worth looking into.

🙂 Expected behavior

Object is not assignable to functions with different return type

Additional information about the issue

No response

[RyanCavanaugh]

It's declared as having a (): any; call signature since the definition predates the existence of unknown/object and types deriving explicitly from Object are obviously free to be ~anything. I don't see much upside in changing that -- this is basically the only observable effect of that.

[szacskesz]

Wouldn't it be better to have an unknown return type for the callable signature (): unknown;, and let the descendants specify it more if they want?
To me it makes more sense, and it would be consistent with the Do's and Don'ts you wrote about declaration files too:

In cases where you don’t know what type you want to accept, or when you want to accept anything because you will be blindly passing it through without interacting with it, you can use unknown.

[rotu]

I think object would be more appropriate than unknown. The return type of Object is known to not be a primitive type and can be used where an Object is required, e.g. as the key of a WeakMap. See also e.g. #57000

Also, it's confusing that Object() and new Object() have different return types. Not sure if intentional.

[matAtWork]

Can I suggest more strictly typing this as:

type Boxed<T> =
    T extends number ? Number :
    T extends string ? String :
    T extends boolean ? Boolean :
    T extends bigint ? BigInt :
    T;

declare global {
    interface ObjectConstructor {
          assign<T extends {}, U>(target: T, source: U): Boxed<T> & U;
          new <T>(value?: T): Boxed<T>;
          <T>(value: T): Boxed<T>;
      }
}

This mirrors how all mainstream JS engines actually handle primitive types passed to Object(p) and Object.assign(p,q), and avoids a problem with type checking here: samchon/typia#911 (comment)

It's more than possible my basic augmentation is incomplete, but any is certainly a poor choice for modelling the actual behaviour of these expressions.