[proposal] Generalize array initializer syntax

[controlflow]

C# has array initializer syntax from version 1.0, simply inheriting similar syntax construct from C/C++/Java languages:

class ArrayInitializers {
  private readonly int[] xs = {1, 2, 3};
  public int[,] Values { get; } = {{1, 2}, {3, 4}};
  void M() {
    string[] localArray = {"abc"};
    int[,] matrix = {
      {1, 2, 3},
      {4, 5, 6},
      {7, 8, 9}
    };
  }
}

Array initializer syntax seems to be a bit obsolete nowadays, mostly because it don't mix well with var locals (array initializers only work when right hand side of initialization has explicit type). However, in C# we still have explicit types annotations in class members:

class C {
  public static readonly Dictionary<int, string> StaticData = new Dictionary<int, string> {
    {12, "I guess, practically every"},
    {34, "C# programmer"},
    {56, "wrote code like this"}
  };
}

We can reduce the amount of type annotations boilerplate here by:

• Allowing var at type member level - complicates type checking and IDE tooling so much:

  public static readonly var StaticData = new Dictionary<int, string> {
    {123, "abc"},
    {456, "def"}
  };

• Introducing constructor type arguments inference - using collection initializer expressions to infer Dictionary type seems to be overly complex solution (+ we still have to repeat Dictionary type usage):

  public static readonly Dictionary<int, string> StaticData = new Dictionary {
    {123, "abc"},
    {456, "def"}
  };

• Extending array initializer syntax to work with arbitrary types, by making it behave exactly like C# 3.0 collection initializer:

  public static readonly Dictionary<int, string> StaticData = {
    {123, "abc"},
    {456, "def"}
  };

The generalization of array initializers looks similar to the idea of declaration expressions - just like "we already have out/ref-parameters, we can't drop them for good, let's make them more usable", generalization of array initializer syntax simply extends the usability of existing language syntax constructs in the modern days, since collection types dominate over plain CLR array types so much.

  var xs = new HashSet<string> {"abc", "def", "ghi"};
  var ys = new HashSet {"abc", "def", "ghi"};
  HashSet<string> zs = {"abc", "def", "ghi"};

  List<int> list = {firstItem, secondItem};

The only real difference with collection initializer is implicit parameterless constructor call. Instantiated type is determined purely by left hand side of initialization.

[svick]

Allowing var at type member level - complicates type checking and IDE tooling so much

Eric Lippert wrote an article about this in 2009. He says that doing this would require "deep re-architecture of the compiler". Though one deep re-architecture of the compiler later, things may be different. (He mentions other issues too and also proposes a new() syntax to solve the issue.)

Introducing constructor type arguments inference - using collection initializer expressions to infer Dictionary type seems to be overly complex solution (+ we still have to repeat Dictionary type usage):

public static readonly Dictionary<int, string> StaticData = new Dictionary {
  {123, "abc"},
  {456, "def"}
};

This sounds like duplicate of #2319 (and this specific syntax has the same ambiguity issues as that proposal).

[jrmoreno1]

Giving your bullet points numbers 1,2,3 -- are you saying that 1 and 2 have flaws, but would like to suggest 3? Or are you suggesting that all 3 be done, and just listing some cons for 1 and 2?

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this. Also, it appears to bundle together more than one feature request in a single issue.