You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Both simple and substitution templates for all emit targets
Tagged template parse/emit solely for ES6 (and above) targets.
Syntactic highlighting in the LS for template literals
Completion lists in substitution position.
Things that will be done in a separate commit:
Type checking for tagged template expressions by checking assignability of substitution expressions to respective tag parameters.
Add typings for the "cooked strings" parameter of tags.
Patch up parts of the languages service that don't account for templates.
Better parse errors for places that expect string literals.
Experiment with brace matching on substitution templates.
Experiment with indentation in the language service.
Questions worth asking:
Do we want to accept simple (non-substitution) templates in places we accept string literals (i.e. module names, overloading on string constants, etc.)? On one hand, it would seem more consistent with the rest of our language, but ECMAScript 6 does not accept them in property names.
When indexing with a template literal, should we try to perform a static property lookup?
Are void-typed items allowed to be in substitution position? Are there any restrictions on what can be go in a substitution expression?
The reason will be displayed to describe this comment to others. Learn more.
Explain why this is correct. I believe it's because we rewrite this to string addition, and string addition allows the other side to be of any type. So we don't need to check for things like void types, etc. But it would be good to comment this bit.
"Do we want to accept simple (non-substitution) templates in places we accept string literals (i.e. module names, overloading on string constants, etc.)? On one hand, it would seem more consistent with the rest of our language, but ECMAScript 6 does not accept them in property names."
I would say no. I'm not sure we have a reason to be more lenient than ES6.
I just noticed that this ES6 feature is still a proposal, so why implement it already? Not that it isn't great and useful, just wondering why focusing on things that are still status: Draft on ES6 specs. I guess you have your reasons, just wonder what they are ;)
It's actually pretty much nailed down, and it's very unlikely that it will be removed/modified drastically. If anything does change, we'll be very mindful in addressing that. =)
Hi there, I realize that this is on the Roadmap for 1.4. I'm curious though if we might see it sooner as perhaps an experimental option. My team and I would certainly love to start using this sooner rather than later to clean up our code :-)
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request is meant to add support for ECMAScript 6 templates and address suggestion #13.
Right now this branch supports:
Things that will be done in a separate commit:
Questions worth asking: