Notes for brainstorming on how the "final" design of virtual fields:

1. fields may be abstract in which case they must be overridden
2. fields may be virtual in which case they may be overridden
3. all access to a field by name is thru getter and setter (different than our previous rule where access internal to class was to direct storage)
4. access to field storage is done using the new @ storage operator
5. only the declaring class (or first override of abstract fields) can use @ to access storage directly
6. if and only if @ is used on a field inside its definition will the compiler emit the new Storage flag such that the runtime emits an actual storage location for the field (thus abstract fields, overridden fields, and calculated fields won't actually require any memory)
7. overridden fields can specify a new default value, getter, or setter in any combination - anything not specified is inherited (in the case of overriding an abstract field, then null default, and default getter and setter will be used)
8. it is a compile time error to access a field other than thru @ or super in that field's getter or setter
9. I will investigate making fields covariant

Example:

class A
{
  Void m() { x = x + 1 }
  virtual Int x { get { return @x } set { @x = val } }
}

class A : B
{
  override Int x { set { check(val); super.x = val } }
}

In the example above access to x inside A.m is strictly thru the getter and setters. Inside x's getter and setter, only the storage may be accessed using the @ storage operator. In B we override x's setter, calling super.x to actually store the value (done in the A.x setter).