Typecheck passes for incorrect assignment

[canonic-epicure]

Hello,

This code typechecks fine:
const some : ((arg : string) => boolean) = () => true

In the same time it looks obviously incorrect. Since the "arg" in the type definition is not optional. So the function w/o argument is assigned to the variable, which has a type of function with 1 argument.

I'd understand if this would typechecks (it does)
const some1 : ((arg? : string) => boolean) = () => true
but not the above.

I've tried running it with --strictFunctionTypes and it typechecks as well.

[j-oliveras]

Working as intended: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-with-fewer-parameters-assignable-to-functions-that-take-more-parameters

[canonic-epicure]

Huh, optimizing typechecking for the "Array.forEach()" case is kind of weird. In any well-typed language those types are clearly different.
The note from the FAQ:

But forEach should just mark its parameters as optional! e.g. forEach(callback: (element?: T, index?: number, array?: T[]))

This is indeed how the signature for the "forEach" should have looked like.

Now consider this example:

interface Something {
    doSomething : (a : number, b : string, c : string[]) => string
}

const b : Something = {
    doSomething : () => ''  // TYPECHECKS ??
}

b.doSomething() // DOES NOT TYPECHECKS

Behavior is very inconsistent.

[canonic-epicure]

Check this example as well. Again, different behavior:

interface Something {
    doSomething : (a : number, b : string, c : string[]) => string
}

class SomeClass implements Something {
    doSomething : () => '' // TYPECHECKS ??
}
var b = new SomeClass()

b.doSomething() // TYPECHECKS ??

[canonic-epicure]

The logic from the FAQ entry is not correct:
This is not what an optional callback parameter means. Function signatures are always read from the caller's perspective. If forEach declared that its callback parameters were optional, the meaning of that is "forEach might call the callback with 0 arguments".

Indeed, signatures are read from the caller's perspective. But the caller in this case is not the "forEach" method, but the one that calls "forEach" itself. It just happens that "forEach" will provide all three optional arguments to its callback. The caller of "forEach" may consume arbitrary number of them, or even none.

[ahejlsberg]

This is working as intended and the wording in the FAQ is indeed correct. In your examples above, it is safe to treat a SomeClass as a Something because you can safely ignore arguments you aren't interested in. The implements keyword doesn't mean "must implement with exactly the same signature", it just means "must implement so you can safely be treated as".

[canonic-epicure]

Sad to hear. Obviously wrong from my perspective. It is safe to add arguments, not remove.

[canonic-epicure]

Following your logic "you can safely ignore arguments you aren't interested in" basically means - it is safe to ignore mandatory argument for function. Does not make sense for me.

[RyanCavanaugh]

There are dozens of issues where people have argued about this (start at #17868); we don't need another. This is the intended behavior.

[canonic-epicure]

It is a very strange way of running a language business - compromise type safety in return of some ad-hoc convenience for few methods of the built-in lib.

If you have some experience with any language with proper type systems (Haskell, Idris) then const some : ((arg : string) => boolean) = () => true is an obvious type contract violation. Type says - this value is of type "function that accept one mandatory argument". Then assignment operator breaks the contract.

It is very strange way to think about the type (arg : string) => boolean as "a function that accept a string argument and return boolean, OR a function w/o arguments that returns boolean". Thats a sum type. If user's intention would been to define such type, s/he would explicitly used "|".

The callbacks for native methods can be defined as sum types instead:

type forEachCallbackType0<T> = () => void
type forEachCallbackType1<T> = (value: T) => void
type forEachCallbackType2<T> = (value: T, index: number) => void
type forEachCallbackType3<T> = (value: T, index: number, array: T[]) => void


type forEachCallbackType<T> = forEachCallbackType0<T> | forEachCallbackType1<T> | forEachCallbackType2<T> | forEachCallbackType3<T>

Now this is a "it-was-always-like-that-and-we-will-not-change-it-because-it-may-break-something" thing and If I'm correct many people made their reputation, advocating for the current state of things. But it does not become correct because of that. Its obviously wrong.

[j-oliveras]

An optional or required parameter is from the perspective of the caller.

[RyanCavanaugh]

You're begging the question. Ignored extra arguments are both common and safe in JavaScript; it's only "unsafe" if you think ignoring extra arguments is unsafe, and it isn't except by your own fiat.

It makes no sense to require everyone writing a calling-back function to write out N + 1 explicit overloads if they supply N arguments.

[canonic-epicure]

Everyone writing a calling back function and willing to make it flexible in terms of arguments will make them optional, thats all. In fact, an optional arguments is exactly equivalent of the sum type above.

But a hole in the typechecker still remains:
const some : ((arg : string) => boolean) = () => true
And you deliberately ignore it. This has nothing to do with the callbacks. Its a problem on its own. You solved a "callbacks problem" by compromising type-safety.

[RyanCavanaugh]

Everyone writing a calling back function and willing to make it flexible in terms of arguments will make them optional, thats all

This is covered in the FAQ! You should read it! https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-with-fewer-parameters-assignable-to-functions-that-take-more-parameters