[This has been merged](https://github.com/jashkenas/coffeescript/pull/4300) and released as part of CoffeeScript 1.11.

As part of CoffeeScript 2, we will update CoffeeScript’s`class` to output an ES`class` keyword, so that ES2015 classes can be extended and so that CoffeeScript classes can be extended in ES. We will also revise CoffeeScript’s class output to handle`this` in a constructor before calling`super`, and any other changes we need to make to adhere to ES syntax.Thisis the “must-do” part of classes; improving the output by making it more idiomatic (not using`prototype` or`__super__`, etc.) is a separate item under Medium Priority below. This is in progress at[jashkenas/coffeescript#4354](https://github.com/jashkenas/coffeescript/pull/4354).

[Thishas been merged](https://github.com/jashkenas/coffeescript/pull/4354) into the`2` branch.

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.

Building off of the essential class-related items in Top Priority, this item is for the nonessential items like removing our dependence on`prototype` and`__super__`, and generally cleaning up our output and making it more idiomatic. This is where we would also add support for getters and setters[(#17)](https://github.com/coffeescript6/discuss/issues/17) and the`static` keyword. This is in progress at[jashkenas/coffeescript#4354](https://github.com/jashkenas/coffeescript/pull/4354).

CoffeeScript’s`super` should always be compiled to ES2015’s`super`. This is in progress at[jashkenas/coffeescript#4424](https://github.com/jashkenas/coffeescript/pull/4424).

Classes should support getters and setters[(#17)](https://github.com/coffeescript6/discuss/issues/17) and the`static` keyword.

These are nice-to-have features that should be implemented as time permits, probably only in the “new” compiler if one gets created. Any change that causes ES2015 output and isn’t opt-in needs to either be enabled by a flag or only in the new, ESNext-outputting compiler.

[This has been merged](https://github.com/jashkenas/coffeescript/pull/4311) into the`2` branch.

[This is has been merged](https://github.com/jashkenas/coffeescript/pull/4306) and released as part of CoffeeScript 1.12.

These are featureswe’re not sure we will implement, in any version of CoffeeScript:

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

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.

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.

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.

When a variable isn’t declared using a new operator that produces`const` (see above), CoffeeScript should automatically declare it with`let` whenever possible.

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