Collection expressions: Allow builder-pattern method to return different type than the type being built.

[CyrusNajmabadi]

Proposal

This issue contains a change request to the current collection expressions specification that the working group would like to bring for LDM consideration.

The core use case we want to support is relates to the following APIs in the BCL. First, these types, with these members exist today:

public interface IImutableList<T> { /* ... */ }

[CollectionBuilder(typeof(ImmutableList), "Create")]
public class ImmutableList<T> : IImutableList<T> { /* ... */  }

public static class ImmutableList
{
    public static ImmutableList<T> Create<T>(ReadOnlySpan<T> values);
}

With the above, the user can write the following:

public class C
{
    public ImutableList<X> Values { get; } = [GetValue(a), GetValue(b), GetValue(c)];
}

But they cannot write:

public class C
{
    // this is the interface, not the concrete type
    public IImutableList<X> Values { get; } = [GetValue(a), GetValue(b), GetValue(c)];
}

This doesn't work because IImutableList<T> is currently not something the compiler knows how to create. This is unfortunate given such a canonical implementation. Fortunately, a solution seems readily available. Specifically, update the interface like so:

+ [CollectionBuilder(typeof(ImmutableList), "Create")]
public interface IImutableList<T> { /* ... */ }

Bringing it in line with the class. With this, the compiler would now be able to find ImmutableList.Create as the way to initialize C.Values. However, as the spec is currently written, this would not work. Specifically, the specification says:

For the create method:

• ...
• There is an identity conversion between the method return type and the collection type.

Here the method return type is ImmutableList<T> (the concrete type) while the collection type is IImutableList<T> (the interface type). This is not an identity conversion, so this is not allowed.

However, given how trivial this is to support, and given that the BCL is fine adding these attributes to these collections (see PR here), we propose tweaking the above rule to one of either:

1. There is an implicit conversion between the method return type and the collection type.

In other words, allow the user's code above because it would be equivalent to:

public class C
{
    public IImutableList<X> Values { get; } = ImmutableList.Create(GetValue(a), GetValue(b), GetValue(c));
}

Given that the full form would be legal to write there, requiring an exact implicit conversion, instead of any implicit conversion is just onerous.

Costs here are minimal. BCL PR is already done, and runtime has indicated they are fine with this sort of pattern. Compiler PR would just be a minor tweak to the check, along with tests to validate behavior.

Alternatives

One suggestion would be to add the [CollectionBuilder(typeof(...), "Create")] attribute to tehse interfaces, and have them point at methods that do return an instance of the exact interface type the attribute is on.

The runtime team is against this. They would be creating additional, highly redundant, surface area just to work around this limitation in the current specification. The methods would be clones (or dispatchers) to the existing methods, and would need to find some new place to live, or would live next to the existing Create methods, just with different names. This would be extra code, apis, and docs for methods users themselves would never be expected to call.

Conversely, the runtime already has the existing Create methods which work perfectly for our needs, if we're just willing to call them and not have this restriction interfere. So that seems to be the simplest, clearest, and most desirable path for both teams.

[bernd5]

That would be great.
But ff we don't want to change the current proposal, the runtime team could specify another Create method e.g. CreateInterface.

So we would get:

public static class ImmutableList
{
    public static IImmutableList<T> CreateInterface<T>(ReadOnlySpan<T> values) => Create<T>(values);
    public static ImmutableList<T> Create<T>(ReadOnlySpan<T> values){  
}

[CollectionBuilder(typeof(ImmutableList), "CreateInterface")]
public interface IImutableList<T> { /* ... */ }

[CollectionBuilder(typeof(ImmutableList), "Create")]
public class ImmutableList<T> : IImutableList<T> { /* ... */  }

[CyrusNajmabadi]

But ff we don't want to change the current proposal, the runtime team could specify another Create method e.g. CreateInterface.

The runtime team expressed explicitly that they did not want to do that. :)

They already have the method. It already has the appropriate shape on inputs/outputs. Adding another method only to workaround the lack of the language not being willing to use the existing method is not something there is willingness to do :)

[jnm2]

I think it would be great to mention the runtime's position in the change request itself, too.

[CyrusNajmabadi]

will add a section.

[KennethHoff]

I don't see a reason why not to allow this.

Btw, is there a requirement that Collection Expressions have to create IEnumerables, or could I use it for any arbitrary type, as long as we add the method to create it from a ReadonlySpan?

[gulbanana]

I have a use case for [CollectionBuilder] without foreachability. I've got an ORM type which looks something like this:

interface IUnloadedSet<T>
{
    void Add(T);
    void Remove(T);
    Task<ILoadedSet<T>> LoadAsync();
}

interface ILoadedSet<T> : IEnumerable<T>
{
    bool Contains(T);
}

Because the non-Loaded interface isn't IEnumerable, we can't create it with collection initializers, even though it has Add(). However, the desired semantics are that the sets aren't necessarily loaded - initializing them with data that happens to be loaded is fine. It would be great to be able to put [CollectionBuilder] on it.

[jnm2]

Thanks for the example! Let's continue to see if this is a common enough need. My personal leaning currently is that it feels a little like a concept mismatch, but I get the convenience part of it and maybe seeing examples would change my leaning.

In the meantime, the workaround would be to pass the collection expression to a helper method which returns your interface type.

[gulbanana]

Pre-collection expressions, my workaround is collection initializers on a concrete instance of the loaded type. It looks like this:

new ORMEntity
{
    Collection = new LoadedSet<OtherEntity>() { otherEntity1, otherEntity2 }
}

I imagine the helper method version could be something like

new ORMEntity
{
    Collection = Set.Create([otherEntity1, otherEntity2])
}

[jnm2]

@gulbanana Can you share your use case in #7744?

[jnm2]

'Memory' is not a collection type (and there's no movement to make it one)

This has now changed: #8144