> > let x = (id: number, name?: string) => { return; };
> hmm, it would make more sense if it was written like that
> > let x = (id: number, name: string?) => { return; };
> But I guess it's more or less ok. But I definitely feel inconfortable with the ! .
I think the point is that typescript currently supports the shown optional parameter syntax, JS could be extended in a conflicting way to that as well.
In the end, if you are using something that extends JS and you expect that any code you write will continue to work in future versions and that the tool will be altered to stay as close to the standard JS as possible as extended features are incorporated into vanilla JS, you're most likely deluding yourself. Much better to accept that the tool should either try to match vanilla JS, in which case you must accept that you may need to refactor to update occasionally, or that it will eventually diverge, but your code will continue to work, and choose a tool that implements whatever strategy is acceptable to you.
> hmm, it would make more sense if it was written like that
> > let x = (id: number, name: string?) => { return; };
> But I guess it's more or less ok. But I definitely feel inconfortable with the ! .
I think the point is that typescript currently supports the shown optional parameter syntax, JS could be extended in a conflicting way to that as well.
In the end, if you are using something that extends JS and you expect that any code you write will continue to work in future versions and that the tool will be altered to stay as close to the standard JS as possible as extended features are incorporated into vanilla JS, you're most likely deluding yourself. Much better to accept that the tool should either try to match vanilla JS, in which case you must accept that you may need to refactor to update occasionally, or that it will eventually diverge, but your code will continue to work, and choose a tool that implements whatever strategy is acceptable to you.