I made a couple tweaks to the compiler to support native fields. Native fields are similar to abstract fields in that they generate a getter and setter, but no actual storage. The emit process will route the Fan getter/setter to the peer class:

class Native
{
  native Int f
}

class NativePeer
{
  public static NativePeer make(Native t) { return new NativePeer(); }
  public Int f(Native t) { return f; }
  public void f(Native t, Int v) { f = v; }
  Int f;
}

Native fields can be virtual or override a superclass, but cannot be const, static, or abstract.

Also as part of this rework, I relaxed the rules for fields in a const class. Previously a const class required that all fields were const fields. Now you can declare fields without any storage in a const class (since without storage a field is thread safe). This means that the following are now allowed in a const class:

• abstract fields: defer to subclass who will eventually have to override in a const way
• native fields: defer to the native implementation to make thread safe
• calculated fields: see docLang

The one that kind of blurs the definition of const is native fields - since we are really using the term const here to mean "thread safe", not necessarily immutable. But there happens to be a bunch of practical places where this is needed:

• Log.level, setLevel
• File.modified, setModified

All these APIs will be refactored into a field signature.