[Proposal]: Better Initialization of Records with Immutable{Collection} Properties

[TonyValenti]

Better Initialization of Records with Immutable{Collection} Properties

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Simply the process of manipulating records which have Immutable{Collection} Properties

Motivation

Records and immutable collections conceptually pair nicely together, however, the immutable collections don't work nicely with records.

Detailed design

Suppose I have a record like this:

    public record Concurrent {
        public ImmutableList<TimeSpan> Timeouts { get; init; } = ImmutableList<TimeSpan>.Empty;
        public ImmutableList<CancellationToken> Tokens { get; init; } = ImmutableList<CancellationToken>.Empty;
        public ImmutableList<Func<CancellationToken, Task>> Tasks { get; init; } = ImmutableList<Func<CancellationToken, Task>>.Empty;

        public ConcurrentWhenCanceled WhenCanceled { get; init; } = ConcurrentWhenCanceled.AbandonChildTasks;
}

It would be nice to be able to say:

                    var Job = new Concurrent() {
                        WhenCanceled = ConcurrentWhenCanceled.AbandonChildTasks,
                        Timeouts = { CommandTimeout },
                        Tokens = { Token },
                        Tasks = { 
                            async Token => {
                                ret = await Method(V1, Token)
                                    .DefaultAwait()
                                    ;
                            }
                        },
                    };

or similarly:

                    var Job = new Concurrent() with {
                        WhenCanceled = ConcurrentWhenCanceled.AbandonChildTasks,
                        Timeouts = { CommandTimeout },
                        Tokens = { Token },
                        Tasks = { 
                            async Token => {
                                ret = await Method(V1, Token)
                                    .DefaultAwait()
                                    ;
                            }
                        },
                    };

However, the compiler doesn't realize that adding items to an immutable collection returns the new collection so you end up having to do something like this:

var Timeout = new Concurrent() with {
                        WhenCanceled = ConcurrentWhenCanceled.AbandonChildTasks,
                        Timeouts = new[]{ CommandTimeout }.ToImmutableList(),
                        Tokens = new[]{ Token }.ToImmutableList(),
                        Tasks = new Func<CancellationToken, Task>[]{ 
                            async Token => {
                                ret = await Method(V1, Token)
                                    .DefaultAwait()
                                    ;
                            }
                        }.ToImmutableList(),
                    };

I propose that immutable collections be recognized by the compiler and their new collection should be used.

Drawbacks

None that I can think of.

Alternatives

This doesn't have to be done but sure would be nice!

Unresolved questions

N/A

Design meetings

N/A

[YairHalberstadt]

How should the compiler recognise these collections?

[TonyValenti]

@YairHalberstadt I believe either:
A) An explicit list
B) By recognizing Add methods that return the parent type
C) By recognizing the Builder child type and using it to construct the new list.

[HaloFour]

While I agree that immutable collections have always suffered from this problem with collection initializers this would still be a breaking change and could have subtle impact on existing code.

[TonyValenti]

@HaloFour - Re braking changes, something I’ve wondered:
Microsoft owns GitHub, right? It would be super awesome if there was a way to parse all C# code on GitHub using “v.X” of a compiler then reparse all of GitHub again using “v.Next” to get an idea of the impact of a given change. Even cooler would be if there was a difference between what the two versions would generate, an automatic PR would be generated that preserves the legacy behavior.

[yaakov-h]

A breaking change is a breaking change and GitHub is not the end all and be all of code storage.

[HaloFour]

Even if such a thing were possible this behavior is 13 years old (predating GitHub!). The use of object initializers like that is not supposed to mutate the property, regardless of the type. I do think that warnings via analyzer to alert users that such an initializer won't actually modify the property. As for initializing and mutating an immutable collection I think another feature/syntax would be better.