Create Keywords.md

[zspitz]

Fixes #341

cc @mhegazy

[zspitz]

microsoft/TypeScript#2536

[mhegazy]

use lower case type names, so as not to mix them with boxed types, Number, String, etc..

[mhegazy]

also add never.

[zspitz]

Fixed lowercase and never

[mhegazy]

thanks @zspitz. since this is intended to be an index of sorts, i would recommend merging them all in one table. left column has one key word, all sorted alphabetically of course. the right column can have multiple links based on the context. for the JS keywords, i would also add links to MDN documentation or ES6 spec.

[zspitz]

since this is intended to be an index of sorts, i would recommend merging them all in one table. left column has one key word, all sorted alphabetically

@mhegazy I'm thinking that an alphabetical arrangement might be important on paper, but within the browser there's not much benefit -- it's always possible to do CTRL+F to find a specific keyword on the page. However, isn't there added value in the grouping - type annotations, type modifiers, member modifiers etc.?
In any case, there is probably no benefit in splitting the Javascript-only keywords from the rest (e.g. class).

[mhegazy]

Well.. then what is the value of this page in general. you can always search this repo for keywords and that should get you close. like class would get you all the relevant areas. I was thinking of this more of a keyword index to get you quickly where you want, so you can look up as, and know it is used in 1. ES6 module declaration or 2. a post fix type assertion operator; similarly async would get you to some documentation about async functions in general.

[zspitz]

@mhegazy

you can always search this repo for keywords and that should get you close. like class would get you all the relevant areas.

I think many people would be coming from the Handbook link on the Typescript website, and not through the repo, thus repo search can't be counted on. Unless the plan is to eventually have that link refer to the repo (similar to the spec), and not to http://www.typescriptlang.org/docs?

so you can look up as, and know it is used in ...

True. But perhaps sometimes you want to look up the available usages (basic type, type modifier, property modifier etc.) and quickly find out from there which keywords can fill each role. (I'm thinking computed enums here, which can be looked up in both directions...). Admittedly, the hard part will be to figure out the different usage groups first.

Perhaps both views are in order?

[DanielRosenwasser]

for-of

[zspitz]

@DanielRosenwasser fixed

[zspitz]

@mhegazy @DanielRosenwasser I think this is pretty much complete. Could you look over it and see if I've missed anything? Any other thoughts?

[mhegazy]

use "Primitive Type" instead of "Predefined type". this is how the TypeScript spec refers to them anyways.

[mhegazy]

this also applies to the rest of the document.

[mhegazy]

sorry for the delay, have been out on vacation for a while. a few comments:

• use "Primitive Type" instead of "Predefined type"
• do not think the syntax column is adding much value, it is not filled for most entries, i would just remove it.
• In the first table, description and category are mislabeled. seems like he description column has the category and the category column has the description .

[zspitz]

@mhegazy Fixed 'primitive type' to 'predefined type', and headings.
RE: syntax column -- When the same keyword has different meanings (like abstract which is applied to both classes and members), the syntax column clarifies the difference between them. This is particularly true when the meanings have little or no relation to each other (e.g. the distinction between this function parameters, and this-based type guards).
I had originally thought to have the syntax in the first column, but I think the order becomes confusing when the syntax doesn't start with the keyword (e.g. for an entry on the default keyword, if the syntax is in the first column -- export default expr -- there's no way to easily identify that the entry is here because of the default keyword).

[metaleap]

Status on this? =)

[zspitz]

@mhegazy @metaleap There are some changes that need to be made here for 2.1 and 2.2. But if the release-2.0 branch is obsolete, and this PR needs to be merged somehow into the master branch, then I guess that should be done first.

[RyanCavanaugh]

Thank you for contributing to the TypeScript Handbook!

We are currently working through a large backlog of open PRs. As part of this, we're asking authors of PRs with active merge conflicts to assess if their changes are still needed, and if so, open a new PR.

For transparency, we are also working on a full-scale reimagining of the Handbook (see the TypeScript Roadmap), meaning we are largely closing down work on the current version of the Handbook. Typo fixes are always appreciated, but any new content should likely wait until the new Handbook is available so that it can be more naturally adapted to that format.

---

Saved reply above; this technically doesn't have merge conflicts but has a ton of unrelated changes in one PR and I'm not comfortable merging it.