let this.field

[eladb]

Instead of the unbelievable annoying syntax for field declarations in classes:

class Person {
  name: str;
  last: str;
  new(name: str, last: str) {
    this.name = name;
    this.last = last;
  }
}
``

Perhaps we can consider something like this:

```js
class Person {
  new(name: str, last: str) {
    let this.name = name;
    let this.last = last;
  }
}

In order to define public fields, we should use getters:

class Person {
  new(name: str, last: str) {
    this.name = name;
    this.last = last;
  }

  pub get name() {
    return this.name;
  }

  pub get last() {
    return this.last;
  }
}

And we can add some sugar to this. Maybe:

class Person {
  new(name: str, last: str) {
    this.name = name;
    this.last = last;
  }

  pub get name = this.name;
  pub get last = this.last;
}

[skyrpex]

Do you know about TypeScript Constructor Assignments?

Basically, you can:

class Person {
  constructor(public name: string, private last: str) { }
}

And the properties will be assigned as either public or private to the class.

[Chriscbr]

Related: #5150

[eladb]

Do you know about TypeScript Constructor Assignments?

Yes, of course and it would be great to support them, but regardless, I think it would be nice to get rid of field declarations.

[Chriscbr]

Here's a more elaborate example based on some existing code in the winglibs repo:

pub class Library {
  extern "./util.js" static sortedArray(arr: Array<str>): Array<str>;

  new(workflowdir: str, libdir: str) {
    let this.dir = libdir;
    let this.name = fs.basename(libdir); // <-- 
    let pkgjsonpath = "{libdir}/package.json";
    let pkgjson = fs.readJson(pkgjsonpath);
    let this.manifest = PackageManifest.fromJson(pkgjson); // <--

    log(this.manifest.name);
    let this.buildJob = "build-{this.name}"; // <--
    let expected = "@winglibs/{this.name}";
    if this.manifest.name != expected {
      throw "'name' in {pkgjsonpath} is expected to be {expected}";
    }
    
    let this.platforms = Library.sortedArray(this.manifest.wing?.platforms ?? []);
    if this.platforms.length == 0 {
      throw "\"{this.name}\" winglib does not have a `wing.platforms` field in its package.json.";
    }
    
    // ...
  }
}

The syntax is interesting theoretically. One thing nice about it is that if you want to go to the definition of a field like this.buildJob from elsewhere in the class, there's still a logical location that your editor can take you to - the span of the let this.buildJob statement.

To me the only risk of this syntax is that it allows the field's type to be omitted. Like with method signatures, I think public APIs such as fields should be strongly-typed (specified by the user, not implicitly determined based on the body of the function). But if let this.x can only be used to define private fields or inherited fields (and new/public fields have to be defined via well-typed getter functions) then that would mitigate the risk in my mind.

Once we add getters and setters it should be easier to add this kind of sugar safely

[eladb]

I agree about public declarations (which I think we should still require as hoisted) but for private fields I don't think it's needed.