Discussion: Allow collection-initializers on non-IEnumerables

[mburbea]

Allow collection-initializers on non-IEnumerables

Summary

Relax the current compilation error CS1922, and allow the usage of collection initializer on any type provided that there is a public Add method that returns bool or void or an in-scope extension method named Add that returns bool or void.

Add may also be generic to allow scenarios like the following to work::
(this is existing behavior)

public class Mapper<T>
{
      public void Add<TProperty>(Expression<Func<T,TProperty>> rule){...}
}
...
var builder = new Mapper<MyType>{
       o => o.Property1,
       o => o.Property2,
       ...
};

To clarify:
The method must return bool or void to avoid unintentional confusion around types like a ComplexNumber, where the Add method returns a new instance.
However, for IEnumerable types nothing changes. Thus this can (and still will) compile despite being very wrong.

var o = new ImmutableArray<int>{45};
Debug.Asset(o.Length == 1); // fails as length == 0.

Motivation

Simply put, not every collection should be enumerated. Additionally, non-enumerable types (like builders) would benefit from being able to use this simplified syntax.
For symmetry purposes dictionary initializers (e.g. new MyType{[3]="k"}) do not require either a getter or IEnumerable to be implemented, so it seems an unusual onus to require enumerability to use a collection initializer.

Drawbacks

TBD?

Alternatives

You can currently implement IEnumerable, and implement the interface explicitly. However, someone can cast your type to IEnumerable or iterate over your collection with a foreach loop.

One alternative could be using a params T[] parameter on your constructor. However, this disables the use of fluctuating generic signatures. Additionally, this requires allocating an array which maybe in-optimal depending on the situation.
Finally, you can also use fluent method chaining. This can work, but there is no language support for this effort and so it could be very verbose and doesn't play well with inheritance. (Requiring re-implementation to get the right behavior.)
e.g.

public class FluentAdderBase {
      private void AddImpl(object o) {...}
      public FluentAdderBase Add(object o)
      {
             AddImpl(o);
             return this;
      }
}

public class FluentAdderChild: FluentAdderBase{
      public FluentAdderChild new Add(object o){
            return (FluentAdderChild)base.Add(o);
      }
}

[jjvanzon]

It helps to say that the collection initializer works with the magic Add method already. Only the compiler seems to also insist the class be IEnumerable, a requirement mburbea would like to get rid of. I already kind of dislike this magic Add method in the first place. Making assumptions based on the method name is the kind loosely-typedness I think we like to avoid as C# developers. A logical thing to introduce then would be an interface IAddable. Thoughts?

[DavidArno]

Hmm, according to Object and Collection Initializers (C# Programming Guide):

Collection initializers let you specify one or more element initializers when you initialize a collection class that implements IEnumerable or a class with an Add extension method.

So the error message, CS1922, is a bug or a lie in this case...

[DavidArno]

@janjoostvanzon,

Making assumptions based on the method name is the kind loosely-typedness I think we like to avoid as C# developers.

public void Deconstruct(out T1 p1, out T2 p2...) ...

Cat's out the bag on that one...

[jjvanzon]

@DavidArno:
I am not seeing the exact text you referred to. But I am playing around with it right now and my Visual Studio is insisting I both implement IEnumerable and put in the magic Add method.

[jjvanzon]

Cat's out the bag...

@DavidArno
I will take your hint and not use any of that pesky type safety anymore. ;)

[mburbea]

@DavidArno, I think that the spec here is just a little vague. It also glosses over the fact that it works for structs too.

A collection initializer may be used when a type implements IEnumerable and has an Add method, or an Add extension method.

@janjoostvanzon, there are a couple of other "magic" methods in C# right now. Like the duck-typing around foreach. Type-safety has nothing to do with it.

[jjvanzon]

@mburbea:

duck-typing around foreach.

Am I missing something? I thought foreach worked with IEnumerable and IEnumerable<T>.

[HaloFour]

@janjoostvanzon

Or anything that happens to have a GetEnumerable that returns something that happens to have bool MoveNext() and T Current.

[jnm2]

await also ducktypes. The ducktyping in both cases enables 100% stack-based iteration and awaiting, whereas interfaces would force the enumerator or awaiter to be on the heap.

See the List<>.Enumerator struct and the TaskAwaiter<> struct.

[HaloFour]

@jnm2

await is half-duck-typed. Whatever GetAwaiter returns has to implement either INotifyCompletion or ICriticalNotifyCompletion. But the rest of the members are duck-typed.

[jnm2]

await is half-duck-typed. Whatever GetAwaiter returns has to implement either INotifyCompletion or ICriticalNotifyCompletion. But the rest of the members are duck-typed.

This is true, but I'd argue that it's still duck typed because those marker interfaces are not used if public struct methods are available. IIRC.

[DavidArno]

await is half-duck-typed

The simple things in life make me happy. That statement (regardless of its likely precision and accuracy) is going to keep me chuckling to myself for quite some time... 😀

[jnm2]

@HaloFour you going to test this or shall I? 😄

Edit: LinqPad shows direct struct calls, no casting, so no runtime enforcement of interfaces. = duck typing.

[jjvanzon]

@HaloFour:

Or anything that happens to have a GetEnumerable that returns something that happens to have bool MoveNext() and T Current.

Sorry to be unaware of this feature of foreach. This source suggests I have to use IEnumerable / IEnumerable<T>: https://msdn.microsoft.com/nl-nl/library/ttw7t8t6.aspx
I am trying to do it without using IEnumerable. It was not as easy as implementing the interface, but what do you know, this compiles:

[TestMethod]
public void Test_Misc_ForEach()
{
    var myCollection = new MyCollectionType2();
    foreach (int x in myCollection)
    { }
}

private class MyCollectionType2
{
    public bool MoveNext() => false;
    public int Current { get; set; }
    public IEnumerator GetEnumerator() => new int[0].GetEnumerator();
}

Would it be strange to suggest that it would be easier for interface implementation to be insisted by the compiler and does that magic performance improvement under the hood?

[gafter]

From the specification:

The collection object to which a collection initializer is applied must be of a type that implements System.Collections.IEnumerable or a compile-time error occurs.

So the compiler obeys the specification, no matter that other pages are more vague. I understand your feature request is to remove this requirement.

[mattwar]

I think the requirement of IEnumerable was meant to catch usage of collection initializers with classes that just happened to have an Add method but were not collections.

[mburbea]

@gafter, you are correct. Sorry I meant to say that guide was a bit vague. Yes, I'd like to remove it.

@mattwar, yes. I realize that things like a matrix.Add or what not wouldn't really make sense, which is why I added the stipulation that for non-IEnumerable classes to get this feature, the add must return bool or void. That way it is unlikely that this add has the wrong intent.

[svick]

@DavidArno That documentation page is wrong, so I have submitted a PR fixing it in the docs.microsoft version of that page: dotnet/docs#1961.

[svick]

@mburbea

The method must return bool or void to avoid unintentional confusion around types like ImmutableArray, where the Add method returns a new instance.

Code like new ImmutableArray<int> { 42 } already compiles (and is also very wrong). Are you suggesting to change that?

[mburbea]

@svick, No. That would be a breaking change. To quote what I said in response to @mattwar.

which is why I added the stipulation that for non-IEnumerable classes to get this feature, the add must return bool or void. That way it is unlikely that this add has the wrong intent.

For types that are IEnumerable there are no changes.
I've updated my proposal to note this behavior thanks again.

[HaloFour]

@svick

Code like new ImmutableArray<int> { 42 } already compiles (and is also very wrong). Are you suggesting to change that?

@mburbea

No. That would be a breaking change.

A breaking change, but perhaps one for the better. Either way, maybe it would be best to have a way through which developers can provide hints to the compiler as to how best emit for a collection initializer? I created #463 thinking that might address these concerns.