I'm looking at my accessors usage, and they are (numbers are not measured):

• 75% "property forwarding"
• 15% lazy initial computation
• 10% validation
• 5% other

because anything that's introspectable is part of the public API and a breaking change if altered. i don't care what the mechanism is, it just has to be solely up to the class author.

separately, public class fields are sugar for statements in the constructor, and statements inside function bodies are never introspectable in the language, nor should they be.

Oh well I can't speak sorry.

It's for Trusted Types, it is being implemented

For simple field wrapping to support public read/private write, I'd argue for this feature proposed in grouped accessors:

class C {
  accessor x { get; #set; } // paired public getter/private setter
  m() {
    this.x; // ok
    this.#x = 1; // ok
  }
}
const c = new C();
c.x; // ok
// can't use c.#x

For more complex cases (like subproperty access), alias is maybe interesting?

I have been tempted to propose something like C#'s "expression bodied methods", which use =>, i.e.:

// C#
class C
{
  int _x = 0;
  public int x => _x; // public getter with shorthand expression body
  public int y {
    get => _x;
    set => _x = value;
  }
}

Which could could cut down on boilerplate for the alias case:

class C {
  #x = { value: 0 }; // for something more complex
  get x => this.#x.value;
  accessor y {
    get => this.#x.value;
    set => this.#x.value = value;
  }
}

// vs.

class C {
  #x;
  get x() { return this.#x.value; 
  accessor y {
    get () { return this.#x.value; }
    set (value) { this.#x.value = value; }
  }
}

Couldn't aliases/forwarding be done with a decorated accessor? It would be a little wasteful of the unused underlying accessor, but there's any number of ways you could write

@alias({get: () => this.foo.bar, set: (x) => this.foo.bar = x})
accessor bar;

or

@alias({owner: this.#foo, prop: 'bar'}) // obviously order matters here, could be lazy () => this.#foo

And if you wanted to define a bunch of them, you could compose your own decorator that saved some boilerplate

@myalias('foo') accessor foo;
@myalias('bar') accessor bar;

where @myalias could effectively "close over" any this.#owner.

The idea with ref is that a ref-expression captures a Reference to an expression and reifies it:

let x = 0;
let rx = ref x; // ref expression
rx.value; // 0
rx.value = 1;
x; // 1

While a ref-declaration dereferences that reference as if it were the roughly the same binding:

let x = 0;
let rx = ref x; // ref expression takes reference

let ref y = rx; // ref declaration dereferences
y; // 0
y = 1;
x; // 1

For the intended use case, only the Reference at the end matters. Consider:

let x = { y: { z: 0 } };

let rz = ref x.y.z;

rz.value will always point to the Reference for y.z at the time the ref was taken even if you change x.y to something else. This is no different from

let y = x.y;
let rz = ref y.z;

the intermediates don't matter, only the trailing Reference

Yeah, I’ve always liked the refs proposal. Just one thing I’m a bit concerned about is the syntax ref x — for example, the syntactic ambiguity of ref (x), and also that ref a.b.c could easily be misunderstood as re-evaluating the entire chain every time.

Maybe a syntax like x.& could be an alternative — it has better ergonomics (in my opinion) and can express capabilities more clearly (for example, x.&r could mean only expose read capability). Anyway, syntax is just bikeshed issue.

For alias accessors, the entire chain matters. E.g. suppose I have

class C {
  alias foo = #foo.value 
}

If I replace #foo, I don't want this.foo to still be pointing to the old value (and it's the same for deeply nested objects)

You could potentially do this with a decorator and ref:

class C {
  #x = { y: { z: 0 } };

  @alias(_ => ref _.#x.y.z) accessor x;
}

Where the get/set are replaced with an invocation of the callback that returns a ref you can read from or assign to

e.g.

let foo = .a.#b.c.d; /* property chain literal */

which could throw if your current context doesn't include #b (if it does but a doesn't have it that could throw later)
Especially since in a lot of these use cases, the "root" of the property is not fixed but the chain can be applied to a variety of root objects (e.g. in alias accessors there is an implicit this)

I think arrows and ref might be sufficient. _ => _.a.#b.c.d would generally work find as a deferred way to read a value, you just can't write to it. _ => ref _.a.#b.c.d would let you do both:

let foo = x => ref x.a.#b.c.d;

let obj1 = ...;
let obj2 = ...;

foo(obj1).value; // read
foo(obj1).value = ...; // write

foo(obj2).value; // read
foo(obj2).value = ...; // write

rbuckton: What about a leading . ? I have a hunch it would be ambiguous or break existing stuff in some cases, but I can't think of any offhand. It seems like it could be quite elegant if it worked. E.g.

class C {
	@alias (.#foo.value)
	accessor value;
}