from 'x' import { y }

[ghost]

Is it too late to change the import statement around? (I know it probably is).
If it was

from 'x' import { y }

Tooling could provide very handy intelli-sense about what could be imported.

[DanielRosenwasser]

Duplicate of #2371 and #4880.

From my comment in #4880 (comment):

While the import syntax doesn't lend well to intellisense/completion, I don't think it would be appropriate to deviate from ES6.

As @danquirk suggests in #2371 (comment), our IDE experience should compensate for this problem using something like snippets.

I hate to have to close these, but it's for the best that we don't create another import syntax.

[ghost]

@DanielRosenwasser What would be valid reasons for TS deviating from ESx? (and how is JSX less of a deviation than the above?) If no valid reasons, then either TS will soon be much less relevant, or it will continue to be a 'superset' of ESx, implying language syntax and semantics a developer will be 'coupled' to (if their are valid reasons, then how does the above request fall outside them? how are they measured?). In other words, on one hand why should I continue investing in TS if its just ESx, or if on the other, a 'superset', then why can't TS deliver real-world productivity improvements as I'm coupling to it anyways? There are other IDEs with TS intellisense support, and nothing like VS snippets; just curious now what the purpose and soul of TS is

[DanielRosenwasser]

@phestermcs those aren't unreasonable questions, and it's always worth discussing.

One of the biggest issues that we want to avoid is creating syntax that conflicts with future versions of the language. It is conceivable that ECMAScript may eventually introduce a better syntax; however, it might not be exactly the same, or it might be the same and not behave the same at all.

We try to be conservative about new syntax because this is a fairly likely scenario. For instance, the exponentiation operator was something we could have tackled over a year ago, but luckily we didn't because we probably would have picked the wrong syntax, and that would have required a breaking change.

how is JSX less of a deviation than the above?

Actually, JSX was something we were not very keen to do originally either. But JSX isn't something we could really ignore, and those who wanted to use React with TypeScript were having an extremely difficult time. But rather than integrating JSX into a the default language, we created the TSX variant so that we didn't have to create any code breaks.

if its just ESx

But clearly it's not just ESx. The future ECMAScript features are a big plus, but the core value proposition of _Type_Script is the types. That's what powers your IntelliSense support in the first place.

For more info, see our Design Goals.