Theoretically, Javascript is an untyped language, so there aren’t supposed to really be static types. Giving type errors in this situation would be against design.
It’s not a string argument though, it’s JS. You can argue it’s expected to be a string but like the rest of JS all you can know from the signature alone is that it takes an object. Hopefully your little ducky quacks the right way!
Where are you getting these typeless function signatures? You should get them from somewhere else.
The Ecmascript Spec for parseInt doesn’t have a type listed for the first argument, but it does call the argument “string,” which should be a pretty clear hint that it’s expected to be a string. It also explicitly states that the first step of parseInt is to coerce the first argument to a string. You should view older versions of the spec to see how it performs in older browsers / runtimes.
The MDN entry for parseInt makes it clear that parseInt expects a string or a string and explicit radix (i.e., 10 for base 10/decimal, or 16 for hexadecimal). MDN is what I recommend anyone who’s writing JavaScript use as their first resource for core JS features, for what that’s worth.
I use WebStorm to write JavaScript (and more frequently, TypeScript), and if I type parseInt( and pause a second, it pops up a type hint that reads string: string, radix?: number.
I checked in VSCode, too, and it pops up this:
parseInt(string: string, radix?: number | undefined): number`
A string to convert into a number.
Converts a string to an integer.
You can set something similar up with an LSP in Vim or Neovim, and presumably in Emacs as well.
You have argued that it’s expected to be a string congrats. You’ll notice from the grammer you used that there isn’t an actual type here, you specifically pointed out how your IDE displays a type hint which is only slightly better than somebody writing some form of documentation on what the type is. Dynamic languages don’t have typed args, least none that I’ve heard of.
JavaScript doesn’t have typed parameters or variables. The function expects a string and does things in the function body which converts the object into a string. JS shares this behavior with all dynamically typed languages and it’s extremely useful in some contexts and extremely frustrating in others. It’s down to what it’s being used for. Dynamic languages make excellent scripting languages, see Python really just being a souped up shell lang
The function expects a string and does things in the function body which converts the object into a string.
… These are different words that describe exactly what I’m saying. I’m saying: in the place where there should be a string argument, because the function expects one, there is not a string argument, but a number argument. (Not an object like you keep saying.)
I know all that stuff about dynamically typed languages. I’m just saying that the function is being used incorrectly here.
You cannot have a string argument, arguments and variables in JS don’t have a type. All you have in JS is objects. Actual functions, like full on function foo(){}are still objects, like you can actually store data on the things.
I think you confuse argument with parameter. You cannot specify the type of the parameter, but any argument you supply to a function in JS has a type. Every value in JS has a type, arguments included.
If I go:
const n = 0.0000005;
console.log(typeof n);
The code above will print “number”. And you cannot assign n.foo = "metadata"; to this value of a primitive type. Not everything is an object.
Either way, arguments have types, values have types. The arguments in this case were of type “number”, when they should have been “string”.
Agreed, functions in general should do this, and some do. But it should probably be automatic. And the variable argument is a good one, a very good argument for TypeScript. ❤️
Another classic javascript wat
Classic people who don’t know how to code wat. Passing a number in place of a string argument because they don’t know what they’re doing.
Javascript could throw an error to alert you that the input is supposed to be a string, like most languages would do.
But you’re calling a function specifically made for passing a string to an int… 😆 There’s gotta be some common sense somewhere here, guys.
Still, it’s a very good point. JS should do this.
I would suspect one reason it doesn’t do this is to be backwards compatible.
And god fucking forbid that common sense be in the language. Who the fuck needs a language with common sense, amirite?
🤪
Theoretically, Javascript is an untyped language, so there aren’t supposed to really be static types. Giving type errors in this situation would be against design.
Maybe the design is bad, then.
Lol you’ll get no argument from me. It’s not my favorite language.
JavaScript has types and it does have type errors, for instance
> null.foo Uncaught TypeError: null has no propertiesPlease stop spouting nonsense on issues you know nothing about.
Dynamic types aren’t static types my man. I think you got some learning to do.
You did say untyped though.
Lol like facilitate versus effectuate
Function only handles string arguments correctly. Wat.
It’s not a string argument though, it’s JS. You can argue it’s expected to be a string but like the rest of JS all you can know from the signature alone is that it takes an object. Hopefully your little ducky quacks the right way!
Where are you getting these typeless function signatures? You should get them from somewhere else.
The Ecmascript Spec for parseInt doesn’t have a type listed for the first argument, but it does call the argument “string,” which should be a pretty clear hint that it’s expected to be a string. It also explicitly states that the first step of parseInt is to coerce the first argument to a string. You should view older versions of the spec to see how it performs in older browsers / runtimes.
The MDN entry for parseInt makes it clear that
parseIntexpects a string or a string and explicit radix (i.e., 10 for base 10/decimal, or 16 for hexadecimal). MDN is what I recommend anyone who’s writing JavaScript use as their first resource for core JS features, for what that’s worth.I use WebStorm to write JavaScript (and more frequently, TypeScript), and if I type
parseInt(and pause a second, it pops up a type hint that readsstring: string, radix?: number.I checked in VSCode, too, and it pops up this:
You can set something similar up with an LSP in Vim or Neovim, and presumably in Emacs as well.
You have argued that it’s expected to be a string congrats. You’ll notice from the grammer you used that there isn’t an actual type here, you specifically pointed out how your IDE displays a type hint which is only slightly better than somebody writing some form of documentation on what the type is. Dynamic languages don’t have typed args, least none that I’ve heard of.
Huh? The code in the image is passing a number argument where there should be a string argument.
And this function is specifically made to parse a string into an int. Apply common sense.
JavaScript doesn’t have typed parameters or variables. The function expects a string and does things in the function body which converts the object into a string. JS shares this behavior with all dynamically typed languages and it’s extremely useful in some contexts and extremely frustrating in others. It’s down to what it’s being used for. Dynamic languages make excellent scripting languages, see Python really just being a souped up shell lang
… These are different words that describe exactly what I’m saying. I’m saying: in the place where there should be a string argument, because the function expects one, there is not a string argument, but a number argument. (Not an object like you keep saying.)
I know all that stuff about dynamically typed languages. I’m just saying that the function is being used incorrectly here.
You cannot have a string argument, arguments and variables in JS don’t have a type. All you have in JS is objects. Actual functions, like full on
function foo(){}are still objects, like you can actually store data on the things.I think you confuse argument with parameter. You cannot specify the type of the parameter, but any argument you supply to a function in JS has a type. Every value in JS has a type, arguments included.
If I go:
const n = 0.0000005; console.log(typeof n);The code above will print “number”. And you cannot assign
n.foo = "metadata";to this value of a primitive type. Not everything is an object.Either way, arguments have types, values have types. The arguments in this case were of type “number”, when they should have been “string”.
Could be a variable from somewhere else in the code. It should throw type error of some sort if it’s not going to handle a float correctly
Agreed, functions in general should do this, and some do. But it should probably be automatic. And the variable argument is a good one, a very good argument for TypeScript. ❤️
What do you mean, you don’t use string parsing method to round to integers? /s
Love you 😆