Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

for-loop: Type 'number' is not assignable to type 'never'. #10721

Closed
maiermic opened this issue Sep 6, 2016 · 5 comments
Closed

for-loop: Type 'number' is not assignable to type 'never'. #10721

maiermic opened this issue Sep 6, 2016 · 5 comments
Labels
Question An issue which isn't directly actionable in code Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@maiermic
Copy link

maiermic commented Sep 6, 2016

TypeScript Version: 2.0.2

Code

// example.ts
function stoBA(d: string): number[] {
  var b = [];
  for (var c = 0; c < d.length; c++) {
    b[c] = d.charCodeAt(c)
  }
  return b
}

Expected behavior:
No error.

Actual behavior:

example.ts:5:4
Type 'number' is not assignable to type 'never'.
@thetrompf
Copy link

thetrompf commented Sep 6, 2016

You need to type annotate b to an array of number. An empty array is of type never without the type annotations.

You could write:

var b = [] as number[];

@kitsonk
Copy link
Contributor

kitsonk commented Sep 6, 2016

or:

var b: number[] = [];
/* or */
var b = <number[]> [];

@maiermic
Copy link
Author

maiermic commented Sep 6, 2016

Thanks, I missed that type annotation. Nevertheless, I find that error message confusing. I only get it if strictNullChecks are enabled. What does this option have to do with this error? b is of type Array which is equivalent to any[]. In the assignment

b[c] = d.charCodeAt(c)

b[c] is of type any and d.charCodeAt(c) of type number. That assignment should be ok. Why does the compiler complain that type number is not assignable to never. b[c] is of type any, isn't it? What causes never?

@kitsonk
Copy link
Contributor

kitsonk commented Sep 6, 2016

I only get it if strictNullChecks are enabled. What does this option have to do with this error?

While strictNullChecks implies that it is just checking for usage of variables that might be undefined or null it really turns the compiler into a very pessimistic mode, where when there are no contextual way of inferring the type, it will choose the narrowest type, instead of the widest type, making it so you as a developer are required to provide more information to ensure your code is working as designed.

So here:

var b = []; // What is supposed to be in this array? So never[]
var c = [ 'foo' ]; // I can guess, so string[]
var d = [ 'foo', 1 ]; // I can guess so (string | number)[]

@thetrompf
Copy link

It is because an empty array is of type never, which any cannot fit in.

On Tue, Sep 6, 2016, 8:35 PM Michael Maier notifications@github.com wrote:

Thanks, I missed that type annotation. Nevertheless, I find that error
message confusing. I only get it if strictNullChecks are enabled. What
does this option have to do with this error? b is of type Array which is
equivalent to any[]. In the assignment

b[c] = d.charCodeAt(c)

b[c] is of type any and d.charCodeAt(c) of type number. That assignment
should be ok. Why does the compiler complain that type number is not
assignable to never. b[c] is of type any, isn't it? What causes never?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10721 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXSZvcjrE9MhUi8wnZC3TPCDq7Wx_tmks5qnawpgaJpZM4J11GR
.

Med venlig hilsen / Best regards
Brian K. Christensen

@mhegazy mhegazy added Working as Intended The behavior described is the intended behavior; this is not a bug Question An issue which isn't directly actionable in code labels Sep 6, 2016
@mhegazy mhegazy closed this as completed Sep 6, 2016
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Question An issue which isn't directly actionable in code Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants