Discussion: immutable objects

[alrz]

Currently members of a readonly struct field cannot be assigned.

readonly Point point = new Point(..);

point.X = 1; // ERROR

We could add the same functionality to classes using the immutable modifier (on locals, params and fields).

immutable int[] array = { .. };

array[0] = 1; // ERROR

Unlike readonly, immutable objects are deeply immutable and only allowed to call instance methods with an immutable receiver, i.e. this.

struct Point 
{
  public void Offset(int dx, int dy) { ... }
  public int M() immutable { ... } // can't mutate `this` or any instance member
}

immutable Point point = new Point(..);
point.Offset(..); // ERROR
point.M(); // OK

The immutable modifier on a type would make all its methods implicitly immutable.

An analyzer can suggest to make a method receiver immutable if it already satisfies these constraints.

For the shorthand form (where the type is inferred) we can use val since we are maintaining "referential transparency" with immutable objects and it's safe to say that they are "values" rather than "variables."

val point = new Point(..);

It is necessary to maintain a concept of "ownership" (a la Rust) with immutable objects, so that we can not mutate an object after it's being assigned to an immutable variable. for example:

var p = new C();
p.Mutate(); // OK
val q = p;
p.Mutate(); // ERROR

Open question: what are the interactions with ref (including readonly ref, ref locals and ref returns)?
Open question: how this affects captures in lambdas and local functions?

Related to: https://github.com/dotnet/roslyn/issues/159, #955

[shaggygi]

Linking this ([Question/Proposal] Immutable Parent Child API) just in case there are common discussions that come up.

[omariom]

Interesting paper on the subject

[alrz]

In spite of that, I don't see a lot of attention from core team on this subject in Roslyn. I don't even know if it is something that is going to make it to C# eventually. We already duplicated the number of collection classes in dotnet core to support immutability. Perhaps @jaredpar could clarify if it is something that is going be considered in a future version at all.

[gulshan]

I think related- https://github.com/AArnott/ImmutableObjectGraph

[shaggygi]

I believe Records, which is supposed to come in C# 8), will help me with part of my problem. I'm not sure about the parent/child I'm looking for. The LDM noted records could help with Roslyn Syntax Trees.

[Richiban]

Although I'm a fan of programming with immutable objects, I'm not convinced that giving any type the ability to be either mutable or immutable at point of use is a valuable concept. I currently lean on the side of having, say, an Array type and a separate ImmutableArray type (actually, I really wish it was the other way around but, hey. History.)

One of the reasons for this is that a mutable collection and an immutable collection will probably be implemented very differently -- properly immutable data structures will probably be persistent, something that cannot easily be done with a type that is sometimes immutable and sometimes not.

[alrz]

@Richiban

I'm not convinced that giving any type the ability to be either mutable or immutable at point of use is a valuable concept.

The immutable modifier on a type is a shortcut when all members are immutable, just for convenience (and also to guarantee that no mutating members would be added in the future), although, that is what's proposed in https://github.com/dotnet/roslyn/issues/159 in its entirety which I as well don't think is enough for a language feature for immutability enforcement (there are actually some arguments on this in that thread).

One of the reasons for this is that a mutable collection and an immutable collection will probably be implemented very differently

I agree, with this feature we may still need to have separate implementations for the sake of efficiency, but new patterns can emerge, for example, one of the barriers to use "type views" for immutable collections, is that the compiler does not enforce ownership and the like, but when we do have safety checks around those concepts we might be able to use other mechanisms to provide both immutable and mutable implementations with less code; taking advantage of the compiler to prevent unwanted behaviors.

However, that's not the case for, say, arrays. Using ImmutableArray<T> practically throws away all the optimizations that the compiler might do specifically for arrays e.g. rewriting a foreach as a for. On the other hand, with an immutable T[] you would have best of both worlds and yet you don't need to depend on a separate type.

[louthy]

@Richiban

an Array type and a separate ImmutableArray type (actually, I really wish it was the other way around but, hey. History.)

If you want an immutable array type with a less bulky name, then I have one defined in my language-ext project. It's a struct too, so can't be null.

Obviously language support would be better, but it at least reduces the default inertia toward mutable arrays.

[mattwar]

Would you have to say `immutable int[]' all over the place?

immutable int[] Filter(immutable int[] values) { ... }

immutable int[] array = new immutable int[] { 1, 2, 3, 4, 5}

How would you initialize one programmatically as opposed to my initialized array example?

immutable int[] array = new immutable int[5];
array[1] = 1; // error

[whoisj]

@mattwar what we need is a way to tell consumers of a type that it's immutable.

Psudo-ish code for example:

int[] array = new int[5]; // could also use writable int[] array to declare, but "writable" could be implicit
FillArray(array);
array[1] = 1; // no error

return array as readable int[]; // readable as opposed to writable

[mattwar]

@whoisj did the return array as readable int[] actually change the nature of the array or just tag it in the type system as read only so the language prevents the receiver from changing it?

The problem with having the type system protected a type from the receiver modifying it is no guarantee to the receiver that the instance will not change. Immutable types need to have the guarantee of immutability on both sides.

[alrz]

@mattwar

Would you have to say `immutable int[]' all over the place?

I think not. if the return type is defined as immutable you could use a regular new to instantiate an object of that type. Same would apply to locals as well:

immutable int[] arr = new [] { 1 }; 
val point = new Point();

Note that we should transfer the ownership when we are assigning a mutable var to an immutable one, so that we cannot mutate the first variable afterwards.

var p = new C();
p.Mutate(); // OK
immutable C q = p;
p.Mutate(); // ERROR

did the return array as readable int[] actually change the nature of the array or just tag it in the type system as read only so the language prevents the receiver from changing it?

I intended the latter. This would be a compile-time check (just like non-nullable reference types) and does not affect the type itself.

@whoisj

return array as readable int[];

If the return type of the enclosing member is defined as immutable there is no need to explicitly mention it at the call site. immutable int[] F() { ... return array; } should work just fine.

[AdrienTorris]

An idea to precise the scope of the modification to an immutable object could be to set the immutable keyword on an output parameter :

public bool TryGetSomeList(out immutable List<int> myList)
{
	// myArray can be modify everywhere in this scope but once returned, it's immutable.

	myList = new List<int>(); // valid
        myList.Add(1); // valid
        myList.Add(2); // valid
}

public void MyParentMethod()
{
	if(!TryGetSomeList(out List<int> myList))
		return;

	myList.Add(3); // Error, it's immutable

}

In this way, any object could be immutable, it's the method who decides to apply or not an immutable state on his return value.
It could have sense because in a well-design application, a method could know of his return value can be change in his live or no.

[AdrienTorris]

And it could be the same way for any object, including classes :

public void GetCustomerReport(out immutable CustomerReport customerReport)
{
	// Build the CustomerReport, once returned it's immutable
}

public void GetCustomerSituationOverview()
{

	GetCustomerReport(out CustomerReport customerReport);
	
	customerReport.Total = 100; // Error, because it's immutable

}

Maybe even the immutable keyword could be nullable to let the choice to the caller to apply this restriction or not :

public void GetCustomerReport(out immutable? CustomerReport customerReport)
{
	// Build the CustomerReport, once returned it's immutable
}

public void GetCustomerSituationOverview()
{

	GetCustomerReport(out immutable:true CustomerReport customerReport); 
        // The 'immutable:true' is just a proposition of syntax, 
        // but maybe just the boolean value would be better
	
	customerReport.Total = 100; // Works fine

}

public void GetCustomerSituationOverview()
{

	GetCustomerReport(out immutable:false CustomerReport customerReport);
	
	customerReport.Total = 100; // Error, because it's immutable

}

[mattwar]

How does using a keyword at the call site keep you from calling a mutating method?

immutable List<int> list = ...;
list.Add(5); // <-- how does the compiler know this is bad?

[Richiban]

There's currently no way (that I can think of) of actually making this feature (immutable objects) safe, unless you want to implement it only for arrays (and maybe a few other built-in types) without also having a feature for class implementations that mark methods in some way that mutate the underlying class.

We'd be much better off with immutable types first, which is proposed https://github.com/dotnet/roslyn/issues/159.

[whoisj]

How does using a keyword at the call site keep you from calling a mutating method?

We'd need a way to mark a method as not-mutating. this hole just keeps going deeper, doesn't it?

[alrz]

@mattwar

How does using a keyword at the call site keep you from calling a mutating method?

In order to call a method off of an immutable object it should be declared with an immutable receiver, since List<T>.Add is not declared as such, it will be a compile-time error to call it on an immutable object.

For example,

private int _x;
void Method() immutable // immutable receiver, i.e. `this` (turns to an attribute on the method)
{
  // now the same rules for immutable vars are applied to `this`
  this._x = 5; // ERROR, even though `_x` is not readonly nor immutable
  this.NonMutating(); // OK, only able to call other non-mutating methods on `this`
}

From there, on the call-site, the compiler just need to look at attributes on the method to verify it's safe.

[mattwar]

@alrz sure, that's the way I thought it would have to go. But I was following a conversation about a keyword that would turn any type into an immutable type, without bifurcating any libraries, etc. If you have to get at the implementation of a type and decorate methods to mark them immutable, then you've got a lot more work ahead then just a language feature.

[alrz]

@mattwar

Immutability of the receiver does not depend on anything else but the type itself so an analyzer can detect such methods and mark them as immutable to make them usable in an immutable context outside of assembly boundaries in one go. In return, we would have compile-time guarantees on immutability without duplicating the whole type, one for "builder" and one for the immutable view. For arrays there is also an "underlying type" i.e. T[] that is totally unusable when we're talking about immutability (I think that's why we haven't been using it in Roslyn). This also causes to lose all the optimizations that we could have if we could just use the native array type.

I suppose the issue of bifurcation also applies to non-nullable reference types (and any feature that depends on static analysis like method contracts) because every library needs to opt-in to provide required metadata for clients.

I'll note that the ownership itself that is necessary for immutability enforcement is an important part of this and has been a big win for Rust (and is planned for Swift), for instance.

[jnm2]

@mattwar

If you have to get at the implementation of a type and decorate methods to mark them immutable, then you've got a lot more work ahead then just a language feature.

I think @CyrusNajmabadi said earlier that if you don't have to manually mark the method, then the library author will cause breaking changes without realizing it when they change the internals of the method.

[mattwar]

@jnm2 I'm not arguing against having a way to make methods and types immutable. I was just pointing out that the discussion had drifted to a place where there was an implication that a simple keyword at the use site would magically turn types into immutable version of themselves, and I was trying to show that was not possible.

[mattwar]

Most actual immutable types have API's for creating modified instances of themselves (with methods, etc.) Even if you could declare methods that did not directly change state as immutable or pure or whatever, and then used an immutable keyword at the use site to tell the compiler to not let any code make mutations, you would end up with immutable objects, but also not very useful objects.

Immutable types, need to be designed to work within an immutable paradigm. Co-opting mutable types with compiler magic is not so interesting.

[BoysheO]

I do not thing immutable key word is the best way.Imuutable types is what we need. Actually,we need immutable base types to prevent some mistake can be found before running.Such as 'imint' instead of 'int'.
ex:

        public static void Test(ImmutableArray<int> immutable)
        {
            int count = immutable.Count;
            count++;//coder make mistake
            for (int i = 0; i < count; i++)
            {
                var item = immutable[i];
                Debug.Log(item);
            }
        }

the better way

        public static void Test(ImmutableArray<int> immutable)
        {
            imint count = immutable.Count;
            count++;//ide error
            for (int i = 0; i < count; i++)
            {
                var item = immutable[i];
                Debug.Log(item);
            }
        }

Same issue:(dotnet/runtime#77195)

[yaakov-h]

It sounds like you want #188, which is different to this proposal.

[HaloFour]

See: #188

Doubling the number of types doesn't sound like a reasonable approach, especially since that effectively wouldn't help with any user-defined types.