FR: add config option to force return types

[QwertyZW]

There's an option to configure the compiler to force return types in function parameters, but not the return types of the function themselves.

I would like, with a compiler configuration option, to be able to not allow this to compile

function myAddFunction(a : number, b : number) {
    let myIntendedReturn = a + b;
    return "surprise return type haHA";
}

Initially I had thought that the compiler option: noImplicitAny would serve this purpose. But it does not.

Reasons why I would like something like this:

1. solidify the return type of the function in its declaration
2. allows for code to be analyzed statically by IDEs/editors to provide better autocompletion/correctness checking

For example consider we have these following functions in our symbol autocompletion list

function myNumberAdder(a: number, b : number){
    return a + b;
}

function myStringAdder(a : string, b :string){
    return `${a}${b}`
}

If I was to type

let sum : number = my// here the IDE/editor will know to suggest myNumberAdder as opposed to myStringAdder, which also serves as a check for correctness

[DanielRosenwasser]

Hey @QwertyZW, a few points here.

There's an option to configure the compiler to force return types in function parameters, but not the return types of the function themselves.

The return types can be inferred, whereas in the cases you've mentioned the parameters can't.

Initially I had thought that the compiler option: noImplicitAny would serve this purpose. But it does not.

The purpose of the flag is not to flag locations without annotations, but to flag locations where types can't be properly inferred and fall back to any.

to provide better autocompletion/correctness checking

Like I've mentioned above, you don't need to ensure your functions have return types to do this. Try hovering over any of those functions in an editor with good TypeScript support and you'll see that they don't have the type any

I'll point out that early on I was a fan of this idea, but this sort of predictive completion can be overly restrictive for users. It's not always correct because almost any expression can turn into a ternary expression:

var x: number = myStringAdder("a", "b") === "ab" ? /*...*/

Under the scheme you're suggesting, you'd be restricting yourself to functions that return numbers even though the branches of the ternary are really what you're seeking to make completions on.

Just for the sake of completeness, we can do sorting on completions based on type info, but that's filed under another issue which I can't find at this moment.

---

In general, I think thing if you're looking for this, it's a task better left to a linter like TSLint.

[QwertyZW]

Thank you for the thorough explanation @DanielRosenwasser !

I'm closing this

[kitsonk]

Also to point out, if you don't want surprise returns, you can be explicit about the return type:

function myAddFunction(a : number, b : number): number {
    let myIntendedReturn = a + b;
    return "surprise return type haHA";
}

And as pointed out, tslint has a rule for enforcing this.

[QwertyZW]

@kitsonk I'm aware that I can be explicit about the return types. I wanted to have the option to enforce it. That is all.

I come from a c++ background, and so the inference works the other way round in my head. I'm used to having the return type's declaration enforced, as opposed to the declaration of the type of the returned locals.

int retsInt(){
   auto ret = 1;
   return ret;
}

Although c++ also supports the reverse too

auto retsIntoToo(){
   int ret = 1;
   return ret;
}

This is not something that I have gotten used to yet.

The typescript allows something like this to go through

function retsUndefined(){
    let x;
    return x;
}

The return type is inferred to be undefined instead of any which makes sense in the case of the configuration noImplicitAny: noImplicitAny does not mean 'no Implicit undefined'

My ignorance of the language rules is starting to surface.

I seem to have confused the meanings of inference and implication.

Thanks for the linter hint