Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings
This repository was archived by the owner on Feb 19, 2018. It is now read-only.
/discussPublic archive

Commit99d2c92

Browse files
committed
Update features
1 parentb4b4066 commit99d2c92

File tree

1 file changed

+19
-23
lines changed

1 file changed

+19
-23
lines changed

‎Features.md

Lines changed: 19 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -14,38 +14,21 @@ This is in progress [here](https://github.com/jashkenas/coffeescript/pull/4300)
1414

1515
###Classes[(#22)](https://github.com/coffeescript6/discuss/issues/22)
1616

17-
We have consensus that there needs to be some way for CoffeeScript to output ESNext native`class foo extends bar` syntax, in order to interoperate with libraries that use ECMAScript classes. Waitingona consensus for the approach and syntaxin[#22](https://github.com/coffeescript6/discuss/issues/22).
17+
ECMAScript classes will be implemented via a new`esclass` keyword, that has different syntax from the existing`class` keyword.`esclass` will compile to ES2015`class`, as will its constructor, methods, getters and setters.`super` inside`esclass` will function like ES2015’s`super`. There will be no sugarontop of`esclass`, to avoid building a customization that might get implemented differently by ECMAScriptinthe future.
1818

19-
>**This is a breaking change for the current compiler.** Either the`class` keyword gets redefined, or we’re adding a new keyword to implement the new behavior (and old code that might have used that now-reserved keyword could break). We wouldneed tochoose whether the breaking change wouldbeopt-in (the current behavior unless a flag was set) or opt-out (thenew behavior unless a flag was set). If we go with the “new`esclass` keyword” proposal, the breaking change would likely beopt-*out*.
19+
This is avery minorbreaking change for the current compiler. Any current projects using`esclass` as a symbol (e.g., a variable or function or class name) willneed to berefactored, withthesymbol renamed. This breaking change doesn’t seem major enough to warrant anopt-in flag.
2020

2121
###Template literals[(#28)](https://github.com/coffeescript6/discuss/issues/28)
2222

23-
Some new libraries require support for ECMAScript template literals, which are incompatible with CoffeeScript’s backticks.Waiting on consensusforthe approach andsyntax in[#28](https://github.com/coffeescript6/discuss/issues/28).
23+
Some new libraries require support for ECMAScript template literals, which are incompatible with CoffeeScript’s backticks.Support would be addedfor`myTag"hello #{'wo'+'rld'}"` or`myTag"""some multiline string"""`. Suchsyntaxis currently not allowedinCoffeeScript, so enabling support for it would not be a breaking change.
2424

2525
##Medium Priority
2626

2727
These features aren’t required for CoffeeScript to be used in any project, but there’s great desire in the community for these to be added.
2828

29-
###`const` assignment operator[(#1)](https://github.com/coffeescript6/discuss/issues/1)
30-
31-
For whatever reason,`let` and`const` are among the most popular features introduced by ES2015. Per[#1](https://github.com/coffeescript6/discuss/issues/1), we have consensus that there should be some way to force variable assignment to use`const` instead of`var`. The syntax for such a “`const` assignment” shall be:
32-
33-
```coffee
34-
foo :=42
35-
```
36-
which becomes:
37-
38-
```js
39-
constfoo=42;
40-
```
41-
42-
This has the advantage that it’s not a breaking change; currently`:=` fails to compile.`const` variables must be assigned and declared in the same operation, so such declarations would happen in JavaScript at the same place in your code (unlike`var` declarations which happen at the top of the scope). There is no need to support`?:=`, since by definition constants can’t be reassigned.
43-
44-
Nothing else would be changed by adding this new operator. Normal assignment is handled as it is today, with`var`. Even though using`:=` would cause`const` to be in the generated output, this feature is “opt in” like modules and the same warning would apply about transpiling CoffeeScript’s output.
45-
4629
###`async`/`await`[(#10)](https://github.com/coffeescript6/discuss/issues/10)
4730

48-
An[old pull request](https://github.com/jashkenas/coffeescript/pull/3757) basically implements this feature exactly as we’ve outlined it below, though the PRneeds updating to remove ES5 shims.
31+
>An[old pull request](https://github.com/jashkenas/coffeescript/pull/3757) basically implements this feature exactly as we’ve outlined it below, though the PRcontains an ES5 shim. There is a discussion of whether the feature should be implemented with the shim, only as outputting ESNext syntax, or outputting both (with the ESNext output triggered by a new flag).
4932
5033
`async`/`await` isn’t completely standardized yet; it’s not part of ES2015 or ES2016, though support has started appearing in browsers.[It has reached Stage 4 of ES2017](https://github.com/tc39/proposals/blob/master/finished-proposals.md).
5134

@@ -75,7 +58,18 @@ main = ->
7558
main()
7659
```
7760

78-
>**This is a breaking change for the current compiler.** The`await` keyword is not currently reserved, so adding it as a reserved word would break any code that currently uses`await` as a variable or function name. We would need to choose whether the breaking change would be opt-in (no`await` unless a flag is set) or opt-out (`await` is a reserved word unless a flag is set). This breaking change would likely be opt-*out*.
61+
>**This is a breaking change for the current compiler.** The`await` keyword is not currently reserved, so adding it as a reserved word would break any code that currently uses`await` as a symbol.
62+
63+
###`const` assignment operator[(#31)](https://github.com/coffeescript6/discuss/issues/31) or
64+
65+
###Block assignment`let` and`const` assignment operators[(#35)](https://github.com/coffeescript6/discuss/issues/35)
66+
67+
For whatever reason,`let` and`const` are among the most popular features introduced by ES2015. Awaiting consensus on which of these two proposals we want to adopt, if either. Per[#1](https://github.com/coffeescript6/discuss/issues/1), there seems to be consensus that we want some way to support`const` and probably`let` in CoffeeScript.
68+
69+
If we support`const` only,[(#31)](https://github.com/coffeescript6/discuss/issues/31), a new`:=` operator would be added, e.g.`a := 1` would become`const a = 1;`. This would give us the “throw an error if a`const`-declared variable is reassigned” feature of`const`, plus block-scoping but only for`const`s.
70+
71+
If we support`let` and`const`,[(#35)](https://github.com/coffeescript6/discuss/issues/35), which would be necessary if we want to gain the block-scope aspects of the new`let` and`const` keywords, we would need two new operators:`:=` for`let` and`:==` for`const`. The`:=`-defined variables would get their`let` declarations grouped together at the tops of their blocks.
72+
7973

8074
##Low Priority
8175

@@ -91,7 +85,7 @@ Fat arrows should be transpiled into ES2015 `=>`. They took our good idea, let
9185

9286
**Only for the new ESNext-outputting compiler, or the original compiler behind a flag.**
9387

94-
When a variable isn’t declared using the new`:=`operator that produces`const` (see above), CoffeeScript should automatically declare it with`let` whenever possible.
88+
When a variable isn’t declared using the new operator that produces`const` (see above), CoffeeScript should automatically declare it with`let` whenever possible.
9589

9690
###`for … of`[(#11)](https://github.com/coffeescript6/discuss/issues/11)
9791

@@ -105,6 +99,8 @@ These are ESNext features where a consensus has yet to be reached on whether Cof
10599

106100
###Getters and setters[(#17)](https://github.com/coffeescript6/discuss/issues/17)
107101

102+
Probably need to be supported as part of adding support for ES2015 classes.
103+
108104
##No Action
109105

110106
These are other features that have been discussed, but the consensus at the moment is that no action should be taken to implement them.

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp