Implicit function types

[mindplay-dk]

Suggestion

🔍 Search Terms

implicit function types

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

function literals should implicitly have a type - the same way class literals do.

📃 Motivating Example

Currently, to use dependency injection with functions, I have to explicitly add types for function literals, like so:

function sayHello(user: string) {
    window.alert(`Hello, ${user}!`);
}

type sayHello = typeof sayHello; // 👈 this

function start(sayHello: sayHello) {
    // ...
}

Intuitively, before you try that, you're going to try something this:

function sayHello(user: string) {
    window.alert(`Hello, ${user}!`);
}

function start(sayHello: typeof sayHello) {
    // ...
}

That doesn't work.

Contrast function declarations with class declarations, which "just works":

class HelloSayer {
    // ...
}

function start(sayHello: HelloSayer) {
    // ...
}

Why do class declarations get a type, and function declarations don't?

It's also not unconventional in JS to write "constructor" functions like this:

function HelloSayer(user: string) {
    return {
        sayHello() {
            window.alert(`Hello, ${user}!`);
        }
    }
}

function start(sayHello: HelloSayer) {
    // ...
}

There's even been popular talk of "new keyword considered harmful" over the years.

In JavaScript, the result of a class declaration isn't very different from the result of a function declaration - both result in a function type value in the same scope. Both are declarations parsed during the first pass, meaning you can reference them recursively.

And functions do have a type in TypeScript: you can extract it with typeof, and you can import it from another module with import type, so why is this type "hidden" or inaccessible from type-hints? Why do classes have this special status?

I think this could be "fixed" retroactively without any breaking changes, if declaration merging could be applied, allowing existing code to explicitly declare an identical function-type with e.g. type HelloSayer = typeof HelloSayer, since these would almost definitely have identical types. (Or, at least, this would be a very minor breaking change, only affecting codebases where some types are currently inconsistent with the types of function literals with the same name.)

💻 Use Cases

Dependency injection.

[MartinJohns]

Intuitively, before you try that, you're going to try something this:

function sayHello(user: string) {
   window.alert(`Hello, ${user}!`);
}

function start(sayHello: typeof sayHello) {
    // ...
}

That doesn't work.

It works just fine, if you don't shadow the function name:

function start(sayHelloFn: typeof sayHello) {...}

[RyanCavanaugh]

It would be profoundly confusing (as well as actually a breaking change) to do this.

And functions do have a type in TypeScript: you can extract it with typeof, and you can import it from another module with import type, so why is this type "hidden" or inaccessible from type-hints? Why do classes have this special status?

The implicit type declared by a class is not the type of the value, but the type of the instance shape. What equivalent is there for a function -- maybe its return type? The same goes for enum; the type it declares is not the same as its typeof.

The non-declaration of types here is fully intentional.

[mindplay-dk]

It works just fine, if you don't shadow the function name:

I deliberately shadow names when injecting dependencies.

For one, inventing new names for no practical reason makes for really confusing code.

And for another, when you inject and shadow globals like document or window, you don't want somebody accidentally accessing the global rather than the injected instance of those objects by accident when making a change to the code.

The implicit type declared by a class is not the type of the value, but the type of the instance shape.

But it is the type of the value, e.g. something like: { new(): ... } with the actual instance shape being a structural subtype, the thing that is produced by the function when you apply new to it.

But I'm not trying to debate which types are declared, but the fact that other symbol declarations have a named type - and functions for some reason don't.

It's kind of surprising if you look at the declaration types side by side - it really looks like an inconsistency in the language:

The error message even says: 'Foo' refers to a value and suggests typeof Foo - so the compiler actually knows what it is I'm trying to do, but for some reason is going to make me jump through hoops to do it.

It would be profoundly confusing (as well as actually a breaking change) to do this.

That's a matter of opinion.

Personally, I find it profoundly confusing when languages deviate from their own norms on fine points like this - inconsistency in programming languages is always confusing and frequently frustrating.

I don't think you've made a very convincing argument why function declarations shouldn't work like all other declarations. The outcome of a class declaration in JavaScript is literally the same thing as a function declaration - a local symbol with the same type:

I understand that it's a breaking change - I explained as much in my original post, but also explained why I think it's probably a very minor breaking change, and how this could probably be made backwards compatible with declaration merging.

If it helps you understand why this is important, I wrote an article about it. Software quality is very important to me - and I think that's the main reason anybody chooses TypeScript. If you care about software quality, you most likely apply IOC everywhere, and it's very likely this will lead you to functional programming patterns eventually.

This would just be more natural and easier to explain, if you could simply type-hint parameters against types. Getting an error-message for that is just a distraction, and type f = typeof f is just noise that you have to explain.

I wish you wouldn't dismiss the idea quite so promptly.

[RyanCavanaugh]

I wish you wouldn't dismiss the idea quite so promptly.

This is not the first time this has been suggested, considered, and rejected, nor the first time we've thought about what kinds of declarations should introduce kinds of symbols.

[mindplay-dk]

So you're saying others have felt the need for an improvement here.

What I'm suggesting may not be the answer, but it sounds like there's a real need here?

Or maybe I'm just reaching the point where I'm ready for a real functional programming language, heh 😉

[mindplay-dk]

Maybe this could be an optional feature you turn on via tsconfig?

If this is not a feature you want at all, do you know if it's possible to implement this as a TS compiler plugin? (Since it's a feature that affects type-checking and doesn't change any syntax, an option or plugin shouldn't interfere with use of other compilers like Babel or ESBuild, so that approach might work.)

[MartinJohns]

do you know if it's possible to implement this as a TS compiler plugin? (Since it's a feature that affects type-checking and doesn't change any syntax, an option or plugin shouldn't interfere with use of other compilers like Babel or ESBuild, so that approach might work.)

As per the documentation, language service plugins can't customize the type system.

[fatcerberus]

typeof Class is the type of Class as a runtime value--i.e. the class's constructor, with all its static members attached. Class by itself is the type of object you get by calling new on it. They are completely different types, with no subtyping relationship. There is no equivalent to this dichotomy for regular functions.

As for why regular functions don't have a named type, it's for the same reason let x = 0; doesn't create a named type called x. You have to use typeof x to get its type. Same for functions. typeof gets the type of an identifier that's accessible at runtime. There is no separate runtime representation for the shape of a class instance (you have to actually call the constructor to get an instance), so TS creates a type that you can refer to when you need an instance.