Let and Const

[AlicanC]

Why are let and const omitted in the syntax? Wouldn't having const be useful for declaring read-only properties?

class MyClass {
  // Ugly
  get myConstA {
    return 13;
  }

  // Requires user-land decorator
  @readonly
  myConstB = 13;

  // Perfect?
  const myConstC = 13;
}

---

Also, there is a discussion going on about enums. If enums are going to be implemented with enum myEnum = {Red, Green, Blue}; syntax, then it would be hard to put enums in this spec.

Even if enums won't be implemented like that or even they won't be implemented at all, having users explicitly specify let and const should make this spec a lot more future-proof.

[jeffmo]

One problem with let and const is that they imply lexical bindings (of which properties/fields are not). As far as enums go, if they make it into the language chances are they won't be a new kind of binding -- just a new kind of value; So the syntax is more likely to be something like let myEnum = enum {Red, Green, Blue}; than enum {} -- which will still work with whatever we choose.

All that said, qualifier keywords are still on the table I think. They might also help with some concerns around the fact that currently the syntax for fields with initializers looks like an assignment (rather than a declaration with a deferred expression). I'd been considering something like public, but depending on how private fields play out this may/may not be ideal. I plan to talk about this at the next tc39 meet up.

const would be a nice keyword for some kind of "const" fields, but given that properties != bindings (and there are a lot of other "kinds" of field annotations one might one that have combinatorial mixtures: enumerable, configurable, etc), I think decorators are probably the best means for achieving this class of stuff -- at least to start out with.

[AlicanC]

Fair enough. I'd like to continue the discussion though.

Here is what you can put in the descriptor: configurable, enumerable, value, writable, get and set.

get and set is covered by get prop() {} and set prop(value) {}. value is covered by prop = value;. So what about others? Don't they deserve some sugar?

Since the defaults (not for Object.defineProperty(), but for this spec) is {writable: true, enumerable: true, configurable: false}, we could introduce keywords to invert them:

class MyClass {
  readonly hidden configurable myProp = 13;
}

I like this a lot better than const.

---

Also, when you present an example with decorators like this, it looks great:

class MyClass {
  @configurable(true)
  @enumerable(false)
  @writable(true)
  myProp = 13;
}

But the reality is this:

import {configurable, enumerable, writable} from 'somelibrary';

class MyClass {
  @configurable(true)
  @enumerable(false)
  @writable(true)
  myProp = 13;
}

Having to import a library for something very basic seems bad. I feel like this functionality should be built-in somehow.

[michaelficarra]

I am very very strongly opposed to allowing these properties to be made configurable. If you want that, use a regular assignment in the constructor.

[jeffmo]

I feel like this functionality should be built-in somehow.

You might be right, but I think we need to prove this through experience. There shouldn't be anything here that prevents us from expanding support for things like this in the future if there's significant experience and demand for it, so I'd rather start small with opportunity to grow as needs arise.

Also FWIW, I would expect something less repetitive for a decorators lib like:

import * as dec from "decorators";

class MyClass {
  @dec.configurable(true)
  @dec.enumerable(false)
  @dec.writable(true)
  myProp = 13;

@michaelficarra: I don't think there are any proposals for making properties configurable by default right now, but given that decorators can intercept property descriptors before they are set on the class prototype -- there's no stopping people from doing this in "userland" in terms of a decorator.

[michaelficarra]

@jeffmo I was only referring to the proposal here of a modifier for making the property configurable. I'm okay with the other modifiers, but not that one. Decorators are another conversation.

[AlicanC]

@jeffmo, my concern is the need of a library to make this basic functionality available not the character length of the import statement.

Configurability and enumerability might be left to the userland, but I think at least writability deserves some sugar.

[danwdart]

Definitely for making let/const-able class properties. I'm used to doing const in PHP classes and it's also a nice pattern. +1

[jeffmo]

As mentioned above I'm not opposed to eventually expanding the syntactic capabilities of fields but its certainly beyond the scope of this proposal right now.

Also FWIW: There are others in the committee who wish to see similar kinds of modifiers on class fields in the future -- so I wouldn't worry too much about this idea being tied to this proposal.