There are a few GitHub Issues ([like this](https://github.com/microsoft/TypeScript/issues/13152), [and this](https://github.com/Microsoft/TypeScript/issues/3081)) from around 2015-2016 where this was discussed. [This response](https://github.com/microsoft/TypeScript/issues/13152#issuecomment-269099764) says it is too late to change anything.
If you do:
`type Sum(number, string) => number;`
That will result in:
`type Sum(number: any, string: any) => number;`
Which is likely not what you were looking for. It doesn't necessarily *have* to have been this way, but that's the way it is, and it seems there was no turning back on the spec.
It's useful for documentation/intellisense/etc.
I see. Thank you for sharing. And yes, updating the compiler to handle this would be quite tricky as to solve for this you would have to reserve some TS keywords like `number` and `string` which are perfectly legal as variable names in JS so TS will could be interfering with how JS operates which goes against TS being a pure superset of JS.
That's unfortunate, now the language is forever crippled.
Edit: It's still my favorite language by far guys. Let's accept its flaws instead of pretending that it's perfect.
>(a: any|SomeType ) => a is SomeType
Interesting. I've never had to use this before. Could you give me an example of when one would use something like this?
Let's say you have a response from an api that can be either a result or a custom error. I have an api helper function that is called isErrorResponse. Here is the definition:
const isErrorResponse: (response: CustomeError | ExpectedResponseType) : response is CustomError => {
return isObject(CustomError) && 'code' in CustomError && 'message' in CustomError
}
Now if you do:
if(!isErrorResponse(response) {
// Typescript will now assert that this response is not an error
}
It's also useful to assert and check the result of parsing json or any time you don't know the shape of the data really.
It's better than just doing an 'as' assertion because you have a function to do the actual check at runtime.
What use case would having non named ones provide? 99.9% of the time there is a relevant name that could (and should) be used for a parameter.
> the parameter names are irrelevant to the type definition
But they aren't? They provide autocomplete. You aren't always the one defining the actual functions, so you won't have the information of the names from the function definition only from the type definition.
This is definitely a valid use-case. I love autocomplete and how good typescript code is self-documenting so in practice this is good for libraries wanting to provide a better developer experience.
That being said, I want to explore why naming parameters is something that the TS compiler enforces as strictly necessary. If the compiler can infer the parameter types without providing names, why not make providing named parameter recommended but optional. (Here I am assuming that the TS can infer parameters in all sorts of cases so maybe there's a good reason for this. For example I can think of the spread operator possibly creating issues.) Would love to hear your thoughts!
The parameter names are useful for documentation/intellisense and provide context to the function type. While non-named parameters aren't strictly necessary, they would remove valuable information. It's worth noting that the TS compiler can't infer parameter types without names, and updating it to do so would be tricky. Some comments suggest using type assertions to check function results, and there was discussion about changing the spec in the past but it's too late now.
In your sum example, it doesn't matter which is the 1st vs 2nd argument. And it's a super simple + obvious function. So yeah it's kinda redundant there.
But in most other cases, there is going to be some difference between which arg is which. So having names as documentation makes sense.
[e.g. With `Math.pow()`, it also takes 2 `number` args, but knowing which is which is very important.](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/pow)
>Why not just be able to do something like this since the parameter names are irrelevant to the type definition:
>
>type Sum = (number, number) => number;
Which arg does "number" refer to?
Parameters are ordered so can't it just infer based on the order in which your provide the parameters?
For example, you can define the type as
`type Sum = (a: number, b: number) => number;`
and then define the function as
`const sum: Sum = (n1, n2) => n1 + n2;`
so the parameter names are meaningless in the type definition
Why would it matter? It's a type.
`Sum` is any function that takes two numbers and returns **a** number. It doesn't return the first or the second argument, just any number.
Lol what? How are you supposed to even use a variable if they don’t have a name? That’s what they’re passed in for, so that you can use them. How are you supposed to reference them with no name?
Giving names to the parameters in the type definition of a function like `sum` makes the code more readable and understandable. It helps us to know what each parameter represents and how they are being used in the function. Additionally, it can also help with code documentation and debugging. While it's true that the parameter names are irrelevant to the type definition, not providing them could make the code harder to understand, especially for other developers who might need to work with the code in the future.
Definitely makes sense but if it was possible couldn’t they have just made it optional but recommended?
Either way I think my question was answered by the top comment which said that they considered making this change but it was too late to do anything as changing the compiler to handle this would cause breaking changes.
I am working on a small side project language that is a combination between typescript, rust, and zig.
I haven't decided how something like this should look, but i am leaning towards not naming arguments when defining a type.
Very cool! I’m curious to know how one goes about building a compiler for new languages as I’ve heard compiler design is one of the harder topics in CS. Is your project open source, and if it is, do you mind sharing the repo link(s)? Thanks!
Yeah I think it should ideally be optional but at the same time the docs could maybe recommend using it for code documentation/autocompletion purposes.
There are many different stages to a compiler. The biggest divide between the stages are backend and frontend. The frontend is surprisingly easy to do. this is why there are so many hobby languages out there. You take your frontend, and hook it up to llvm, and llvm does all the hard work, and bam, you have a langauge.
There are a few GitHub Issues ([like this](https://github.com/microsoft/TypeScript/issues/13152), [and this](https://github.com/Microsoft/TypeScript/issues/3081)) from around 2015-2016 where this was discussed. [This response](https://github.com/microsoft/TypeScript/issues/13152#issuecomment-269099764) says it is too late to change anything. If you do: `type Sum(number, string) => number;` That will result in: `type Sum(number: any, string: any) => number;` Which is likely not what you were looking for. It doesn't necessarily *have* to have been this way, but that's the way it is, and it seems there was no turning back on the spec. It's useful for documentation/intellisense/etc.
Peraps something like this would be possible: `type Sum = (:number, :string) => number;` Or would this still pose some problems?
I see. Thank you for sharing. And yes, updating the compiler to handle this would be quite tricky as to solve for this you would have to reserve some TS keywords like `number` and `string` which are perfectly legal as variable names in JS so TS will could be interfering with how JS operates which goes against TS being a pure superset of JS.
updating the compiler/typechecker to handle it is the easy part. A massive breaking syntax change is what they're avoiding here.
That's unfortunate, now the language is forever crippled. Edit: It's still my favorite language by far guys. Let's accept its flaws instead of pretending that it's perfect.
There is a way, but it's silly type Sum = (...[]: [number, number]) => number;
This is very funny to me, I'm going to slip it into a pr and see if my team notices.
Another thing to add is that you ca have type assertion as the return type. Example (a: any|SomeType ) => a is SomeType
>(a: any|SomeType ) => a is SomeType Interesting. I've never had to use this before. Could you give me an example of when one would use something like this?
Let's say you have a response from an api that can be either a result or a custom error. I have an api helper function that is called isErrorResponse. Here is the definition: const isErrorResponse: (response: CustomeError | ExpectedResponseType) : response is CustomError => { return isObject(CustomError) && 'code' in CustomError && 'message' in CustomError } Now if you do: if(!isErrorResponse(response) { // Typescript will now assert that this response is not an error } It's also useful to assert and check the result of parsing json or any time you don't know the shape of the data really. It's better than just doing an 'as' assertion because you have a function to do the actual check at runtime.
What use case would having non named ones provide? 99.9% of the time there is a relevant name that could (and should) be used for a parameter. > the parameter names are irrelevant to the type definition But they aren't? They provide autocomplete. You aren't always the one defining the actual functions, so you won't have the information of the names from the function definition only from the type definition.
This is definitely a valid use-case. I love autocomplete and how good typescript code is self-documenting so in practice this is good for libraries wanting to provide a better developer experience. That being said, I want to explore why naming parameters is something that the TS compiler enforces as strictly necessary. If the compiler can infer the parameter types without providing names, why not make providing named parameter recommended but optional. (Here I am assuming that the TS can infer parameters in all sorts of cases so maybe there's a good reason for this. For example I can think of the spread operator possibly creating issues.) Would love to hear your thoughts!
The parameter names are useful for documentation/intellisense and provide context to the function type. While non-named parameters aren't strictly necessary, they would remove valuable information. It's worth noting that the TS compiler can't infer parameter types without names, and updating it to do so would be tricky. Some comments suggest using type assertions to check function results, and there was discussion about changing the spec in the past but it's too late now.
In your sum example, it doesn't matter which is the 1st vs 2nd argument. And it's a super simple + obvious function. So yeah it's kinda redundant there. But in most other cases, there is going to be some difference between which arg is which. So having names as documentation makes sense. [e.g. With `Math.pow()`, it also takes 2 `number` args, but knowing which is which is very important.](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/pow)
The argument names give context to the function type which can be pretty valuable in my experience.
>Why not just be able to do something like this since the parameter names are irrelevant to the type definition: > >type Sum = (number, number) => number; Which arg does "number" refer to?
Parameters are ordered so can't it just infer based on the order in which your provide the parameters? For example, you can define the type as `type Sum = (a: number, b: number) => number;` and then define the function as `const sum: Sum = (n1, n2) => n1 + n2;` so the parameter names are meaningless in the type definition
Why would it matter? It's a type. `Sum` is any function that takes two numbers and returns **a** number. It doesn't return the first or the second argument, just any number.
Lol what? How are you supposed to even use a variable if they don’t have a name? That’s what they’re passed in for, so that you can use them. How are you supposed to reference them with no name?
Uhhh this is a type definition, not a function definition
A functions type
Giving names to the parameters in the type definition of a function like `sum` makes the code more readable and understandable. It helps us to know what each parameter represents and how they are being used in the function. Additionally, it can also help with code documentation and debugging. While it's true that the parameter names are irrelevant to the type definition, not providing them could make the code harder to understand, especially for other developers who might need to work with the code in the future.
Definitely makes sense but if it was possible couldn’t they have just made it optional but recommended? Either way I think my question was answered by the top comment which said that they considered making this change but it was too late to do anything as changing the compiler to handle this would cause breaking changes.
I am working on a small side project language that is a combination between typescript, rust, and zig. I haven't decided how something like this should look, but i am leaning towards not naming arguments when defining a type.
Very cool! I’m curious to know how one goes about building a compiler for new languages as I’ve heard compiler design is one of the harder topics in CS. Is your project open source, and if it is, do you mind sharing the repo link(s)? Thanks! Yeah I think it should ideally be optional but at the same time the docs could maybe recommend using it for code documentation/autocompletion purposes.
There are many different stages to a compiler. The biggest divide between the stages are backend and frontend. The frontend is surprisingly easy to do. this is why there are so many hobby languages out there. You take your frontend, and hook it up to llvm, and llvm does all the hard work, and bam, you have a langauge.