Align ToString implementations for immutable collections to record types ToString

[svdHero]

In C# 9 record types got introduced which are absolutely awesome. These bring a lot of goodness from immutable data structures as we have them in F# to C# now.

Even better, record types have a nice implementation of ToString which helps for pretty-printing value types easily. However, there is on draw-back: The implementation of ImmutableList<T>.ToString, ImmutableDictionary<K,V>.ToString etc. only print the class name instead of their entries.
This makes the record types ToString useless in practice, since

public record Foo
{
	public string MyString {get; init;}
	public Bar MyBar {get; init;}
	public IImmutableList<int> MyList {get; init;}
}

public record Bar
{
	public float MyFloat {get; init;}
}

Foo foo = new Foo()
{
  MyString = "Hello World",
  MyBar = new Bar() {MyFloat = 47.11},
  MyList = ImmutableList.Create<int>(3, 5, 7)
};

Console.WriteLine(foo.ToString());

prints

Foo { MyString = Hello World, MyBar = Bar { MyFloat = 47.11 }, MyList = System.Collections.Immutable.ImmutableList`1[System.Int32] }

instead of

Foo { MyString = Hello World, MyBar = Bar { MyFloat = 47.11 }, MyList = [3, 5, 7] }

which most developers would desire when using value types and immutable data structures.

Would it be possible to change the ToString implementation for all types from the System.Collections.Immutable namespace? I ask this here, because the implementation is related to the newly introduced language feature of record types, which again are just awesome! Thank you for adding them!

[YairHalberstadt]

This would be a question for dotnet/runtime.

[333fred]

Of note, we considered special handling for arrays or other enumerable types, but we ultimately decided against it because there are many such types that users may want to have special handling, and we feel that it would be better for a source generator or a type's ToString() to handle.

[svdHero]

@333fred I am not so sure about your special handling argument. I would argue that those people who have thankfully adopted record types are the ones who want to use them for immutability reasons. And in this case there are no special desires. With immutable data structures it's all about the values. Nothing else has meaning but the values. So does any other implementation of ToString even make sense, but the one that prints all the values included in an immutable collection? At the same time this would fit in perfectly with the rest of the record type nested printing.

Right now, I wonder if anybody out there is even using a record type's default ToString implementation if it's broken with the first collection that is added to the data structure. And that's a shame, because one of the main purpose of record types was to reduce developer's boilerplate if I am not mistaken. And that has worked out great, except for the ToString implementation that is only half way there and as such not usable in real-life use-cases.

It would be so helpful, if at least for immutable collections the situation would be improved. I can't see how this would have any negative effect.

[HaloFour]

@svdHero

IMO it's the responsibility of the collection, as a value, to print its contents formatted in such a fashion. The record has no concept that the type of value happens to be an immutable collection or anything else. All it knows to do is to have the value print itself.

[333fred]

The point is that we, as a compiler and a language, don't know anything about ImmutableArray or any other collection type. What we do know is that every object has a built-in way of getting a string-representation of the object: ToString. If the object's ToString does not do a good job of representing the object, then it's the object's responsibility to correct that, not the language. That's what I mean by special case: the language would have to actually know about these specific types to do something different than just calling ToString on it, which is what we want to avoid.

[svdHero]

@333fred Okay, that makes absolutely sense. Thank you for clarifying further.