Skip to content

BigInt constructor should not accept any type #38995

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

Closed
wants to merge 29 commits into from
Closed

BigInt constructor should not accept any type #38995

wants to merge 29 commits into from

Conversation

LongTengDao
Copy link
Contributor

Fixes #38980

@InExtremaRes
Copy link

InExtremaRes commented Jun 10, 2020

Why is boolean and object allowed? Just compatibility? BigInt promotes every object to string before convertion and unlike Number (that returns NaN) it throws if the string doesn't represent a valid integer. I guess most of the time passing and object will be a mistake and for valid cases there is always the possibility of converting to string manually beforehand. Also the type object is very "loose" since it allows everything but a primitive, and I feel that most likely pass a function will be non intended, as opposed to call that function an pass the result, for instance.

Wouldn't be better allowing only string | number | bigint first and hope the world doesn't break because of the change?

@LongTengDao
Copy link
Contributor Author

Why is boolean and object allowed? Just compatibility? BigInt promotes every object to string before convertion and unlike Number (that returns NaN) it throws if the string doesn't represent a valid integer. I guess most of the time passing and object will be a mistake and for valid cases there is always the possibility of converting to string manually beforehand. Also the type object is very "loose" since it allows everything but a primitive, and I feel that most likely pass a function will be non intended, as opposed to call that function an pass the result, for instance.

Wouldn't be better allowing only string | number | bigint first and hope the world doesn't break because of the change?

@DanielRosenwasser Any opinion?

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jun 11, 2020

This thing is just a conversion function from another type, so it should be somewhat permissive. The only thing that doesn't work is null and undefined which we're removing.

@typescript-bot test this
@typescript-bot user test this
@typescript-bot run dt

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 11, 2020

Heya @DanielRosenwasser, I've started to run the parallelized Definitely Typed test suite on this PR at 759fff5. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 11, 2020

Heya @DanielRosenwasser, I've started to run the parallelized community code test suite on this PR at 759fff5. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 11, 2020

Heya @DanielRosenwasser, I've started to run the extended test suite on this PR at 759fff5. You can monitor the build here.

@InExtremaRes
Copy link

This thing is just a conversion function from another type, so it should be somewhat permissive.

Yeah, but other "primitive boxes" when called as a function does give a valid value of the primitive type:

Number({})  // -> NaN, a number
Boolean({}) // -> true, a boolean
String({})  // -> '[object Object]', an string
Symbol({})  // -> a new symbol
BigInt({})  // throws :(

Those maybe are just a side effect of the convertion to primitive and could or not be useful, but the type declaration doesn't lie. With BigInt most of the time an object will throw and in other cases TypeScript already prevents a "this is probably a mistake" scenario, even if the ES spec allows a value of any type; IMO this is a good opportunity of doing it as well to obtain a compile-time error instead of a runtime one, a dev can always call BigInt(anObject.toString()) or something like that if that is really the intention.

BTW I think Number() explicitly disallow symbols but it is typed as any as well.

@LongTengDao
Copy link
Contributor Author

LongTengDao commented Jun 22, 2020

In consideration of below code also makes a TS error, maybe what InExtremaRes said is right?

const keyObj = {
	[Symbol.toPrimitive] () :'key' { return 'key'; },
	toString () :'key' { return 'key'; },
	valueOf () :'key' { return 'key'; },
};

( { 'key': 'value' } )[keyObj];

@sandersn
Copy link
Member

sandersn commented Sep 4, 2020

@LongTengDao sorry for letting this get stale. The next step is to see how much (if any) of Definitely Typed packages and our user tests break with this change. I don't see PRs from the last run so I'm going to re-run:

@typescript-bot user test this
@typescript-bot run dt

Once they've run, report back on any failures.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Sep 4, 2020

Heya @sandersn, I've started to run the parallelized Definitely Typed test suite on this PR at 759fff5. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Sep 4, 2020

Heya @sandersn, I've started to run the parallelized community code test suite on this PR at 759fff5. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

@fubar
Copy link

fubar commented Feb 3, 2021

@sandersn what's the status on this? We have bugs go into production because null and undefined are not rejected.

As for accepted values, BigInt({}) throws an error so object should not be included. The specs on accepted values are clear so I'm not sure why this is being discussed in the first place: https://tc39.es/ecma262/#sec-bigint-constructor and https://tc39.es/ecma262/#sec-tobigint @LongTengDao what's the reason you kept object in the list of accepted values? It sounded like the discussion concluded that it should be removed.

@LongTengDao
Copy link
Contributor Author

@fubar One check fails after the commit which removed the object type, and I can't see why by the message (you can visit the red X to read it):

  Error: The configuration file "/home/runner/work/TypeScript/TypeScript/.github/codeql/codeql-configuration.yml" does not exist
      at getLocalConfig (/home/runner/work/_actions/github/codeql-action/v1/lib/config-utils.js:547:15)
      at loadConfig (/home/runner/work/_actions/github/codeql-action/v1/lib/config-utils.js:419:22)
      at Object.initConfig (/home/runner/work/_actions/github/codeql-action/v1/lib/config-utils.js:526:24)
      at Object.initConfig (/home/runner/work/_actions/github/codeql-action/v1/lib/init.js:29:38)
      at run (/home/runner/work/_actions/github/codeql-action/v1/lib/init-action.js:75:31)
      at processTicksAndRejections (internal/process/task_queues.js:93:5)
      at async runWrapper (/home/runner/work/_actions/github/codeql-action/v1/lib/init-action.js:123:9)

@fubar
Copy link

fubar commented Feb 5, 2021

@LongTengDao your fork is well behind upstream, the file exists in upstream but not in your fork. Try pulling latest.

@fubar
Copy link

fubar commented Feb 17, 2021

@sandersn can we get another look at this? Do those tests need to run again? The previous test runs don't have their output anymore, looks like they're too old. Thanks!

@sandersn
Copy link
Member

@typescript-bot user test this
@typescript-bot run dt

@typescript-bot
Copy link
Collaborator

typescript-bot commented Feb 24, 2021

Heya @sandersn, I've started to run the parallelized community code test suite on this PR at f49fdca. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Feb 24, 2021

Heya @sandersn, I've started to run the parallelized Definitely Typed test suite on this PR at f49fdca. You can monitor the build here.

@sandersn
Copy link
Member

@typescript-bot run dt

@typescript-bot
Copy link
Collaborator

typescript-bot commented Mar 11, 2021

Heya @sandersn, I've started to run the parallelized Definitely Typed test suite on this PR at 18b7cc9. You can monitor the build here.

@sandersn
Copy link
Member

DT doesn't have any new errors (although I need to go and clean up the existing errors). The user tests were also clean back in September so I doubt anything has changed.

@sandersn
Copy link
Member

This is now merged in #43204

@sandersn sandersn closed this Mar 12, 2021
@fubar
Copy link

fubar commented Mar 12, 2021

Thank you @sandersn and @LongTengDao

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Backlog Bug PRs that fix a backlog bug
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

BigInt constructor should not accept any type
6 participants