WORM Modifier and Temporality

[WispArchitecture]

Basic Concept

The worm modifier defines a variable that can only be written to only once. This "setting" can occur at any time.
Evaluation/validation occurs on the first attempt to read. The variable is "OK" until then - e.g., a not null could be null at this time.
Once read, (and confirmed valid) the variable is much like a constant.

Background

Dealing with temporality is increasingly becoming an issue in software. Complicating this a move towards "null-less programming". This C# scenario is a typical case that I imagine other .NET languages share.

In C# there are several places where you encounter a "requires a parameterless constructor" error. At the same time, C# has "not-nullable" checking. The effect is that this is a "conditionally valid" class:

class Foo {
   readonly string title; // Not Nullable
   Foo(string title) { this.title = title; }
}

Field title cannot be null (business rule). Requiring a parameterless constructor breaks the class (no way to populate title).
In normal operation, title is created in the initializer phase (uninitialized and "invalid") and populated in the constructor. The system doesn't complain as long as a constructor provides a value. The time between "created" and "valid" is sometimes referred to as the "Temporal Dead Zone". The "not null" check is being enforced at creation, not initialization.

The thing is, not null, like most data, is a Schrodinger thing - we don't (technically) need to know or care if it is null until we try to use it. And in the example case (readonly string title), once it has been read, every read after that will produce the same value output. The title field is WORM data (Write Once, Read Many). But the ability to write is restricted to the constructor body.

The worm (or other keyword) modifier (public worm string title) extends the write period indefinitely. It is a Latch. It can be set at any time by anyone with access (public/private). But once set it cannot be changed - it essentially becomes a constant.

A conceptual implementation associates a state value with any variable that has the worm modifier. (e.g., Void/Created/Set). The runtime should block writing to a "Set" variable, but a first step could leave this to the languages.

A WORM variable helps with, "This field is required when I use the class. I don't know it's value at construction, or the language requires a parameterless constructor, so I can't provide one. But the language requires that I define it here!".

Operationally, worm would suppress "... populated before leaving constructor" type reporting and replace it (later in code) with "attempt to read a worm value before it is set."

At a deeper level, this capability can give object languages a capability they have never had - Associations. Or more specifically,
"constructor-able" compositions that are navigable in both directions! In OO Theory there are two primary constructs - Object and Association. We have class, why not association?

This is one of the most basic constructs in OO modeling. It shows two classes with a bi-directional composition dependency -> A cannot exist without a B being provided at construction (composition), and B cannot exist without A being provided at construction. Circular.

This very basic OO concept cannot be implemented in C#, or directly in the framework (AFAIK).

Using worm can be saying, "Treat this as "valid" for now, I promise I'll set a value before I read it."

Conceptual:

worm A;
worm B;

class A {
    B b; // not null
    A(B b) { this.b = b; }
}

class B {
    A a; // not null
    B(A a) { this.a = a;}
}

A = new A(B);
B = new B(A);

This leads to something like:
(A a, B b) = new Association<A, B>().
(A a, B b, AssociationClass c) = new Association<A, B, C>()

[huoyaoyuan]

First, this belongs to https://github.com/dotnet/csharplang/discussions

We have class, why not association?

Have you checked role/extensions at dotnet/csharplang#5496 ?

[WispArchitecture]

My examples are in C#, and I used association only because bi-directional composition is a good example, but the post is about a "differed latch" variable. It seems this would be useful for many languages and to be efficient, baked into the runtime.

Re: Roles. Roles are different but seem to have some common origin - we commonly assign Roles to ends of associations. One of the broad visions there is "extend/attach to any object". This is really the opposite of associations. Associations (other than possibly composition) should never alter an object's design. We've just accepted they can because that's how our most common languages have been implemented.

[huoyaoyuan]

Generally, DO NOT write a lot about proposed syntax, or even new keyword. Focus on your usage first.
After reading a second time, I can understand your usage about required initialization of bidirectional reference.
It's still suitable to discuss at csharplang first, and then we can discuss if any runtime change is required.