Proposal: Qualifier on variables to make fields of that variable immutable via that reference

[bclehmann]

Example and Explanation

For the sake of this example I will reuse the sealed keyword, but I am not set on this keyword. Especially as it may collide with existing uses of that keyword.

Suppose we have code like this:

public class Bar {
    public int x;
}

public class Foo {
    public sealed Bar data;
    
    public Foo() {
        data = new();
        data.x = 12;
    }
}

Any attempt to modify the fields of Foo.data through the Foo.data reference outside of a constructor or initializer should be a compile-time error. Modifying the reference of Foo.data (i.e. assigning it to another object) should be allowed unless readonly, const, or an init-only setter is specified. Modifying the fields of Foo.data through another reference that is not qualified with sealed shall be allowed.

Range

This qualifier is to be valid on variable declarations, class/struct/record field or property declarations, and return types of functions and methods.

Use in Func or Action style delegates would be nice, but I could anticipate that being more difficult to implement.

Inspiration

This was inspired by the difference between these in C/C++:

• const ​Foo*
  • Mutable pointer to const Foo
  • In C++ modifying the member variables of a const class instance is prohibited, unlike in C#
• int* const
  • const pointer to a mutable int

Motivation

The principle of encapsulation is damaged if a class' member variables can be modified from outside the class. With this suggestion a class can now return a reference which does not have write access:

public class Session {
    private User _user { get; set; }
    .
    .
    .
    public sealed User GetUser() => _user;
}

With the sealed qualifier, code like this will no longer compile:

session.GetUser().FirstName = "Foo";

For what it's worth, it's probably wise to add a shorthand to getter syntax here so we don't need to write getters by hand to use this keyword:

public class Session {
    public User _user { sealed get; private set; }
    .
    .
    .
}

Extras

One should not be able to convert from a sealed qualified object to an unqualified object. One should be able to implicitly convert the other way.

This suggestion was intentionally made so it could be implemented as a compile-time check. However, it could be interesting to designate an object's fields immutable through any reference (or any reference but one) dynamically. This could be used to enforce a class' ownership of a resource.

[HaloFour]

This is an interesting idea but I'd need to hear a lot more details as to how this would be enforced. This would seemingly be very easy to defeat through any means of indirection given that neither the language nor the runtime can track this "sealed"-ness across any API boundaries.

One should not be able to convert from a sealed qualified object to an unqualified object.

This might help mitigate the above, but it also makes the reference nearly unusable through the rest of the .NET ecosystem.

[mattwar]

I think for it to work you would have to propagate the sealed'ness into the type system, so a sealed MyType could not be assigned to a variable of type MyType, only a variable to type sealed MyType. Possibly accesses to members of a sealed MyType would themselves be promoted to sealed and so on. This is somewhat like readonly for readonly structs.