[Proposal]Allow declaring type inferring for type members with in-place initializiers.

[sgjsakura]

C# 3.0 intruduced the keyword "var" for type inferring for local variables. Can it be extended into type members with in-place initializiers?

e.g.

public class Sample
{
  private var data = 1; // type: Int32
  private static var static_data = 1; // type: Int32
  private const data = 1; // type: Int32

  public var Data => 1; // type: Int32
  public var Data3 {get;set;} = 1; // type: Int32
  public var Data2 => Data2; // Maybe OK, but sometimes will cause cycle-dependency problem?

  public var Update() => new Point(1,1); // type: Point
  public var Update2() => Update(); // Maybe OK, but sometimes will cause cycle-dependency problem?
}

I don't know if this is feasible for compilers.

[paulomorgado]

Why do all but const require var? Or why doesn't const require var?

[svick]

@paulomorgado One problem with const var is that it's an oxymoron: is the value constant or can it vary?

[gafter]

@svick var means "variable". It doesn't mean that it can vary. The name comes from mathematics, where the same name might (or might not) bind to different values at different times, but nothing varies or mutates.

[gafter]

It is unlikely we would do this, for two reasons.

First, we believe that types provide valuable documentation at the class level.

Second, it introduces the possibility of cycles in the analysis that the compiler must do to determine types:

class A
{
    public var N = B.M + 1;
}
class B
{
    public var M = A.N - 1;
}

Now, what is the type of A.N?

[sgjsakura]

@paulomorgado Add var after const is also acceptable but seems to be redundancy. In VB when you use Const to declare variables you do not need to use Dim any more. Anyway, this is not a serious problem and they both are OK.

[sgjsakura]

@gafter Yes I agree that cycle dependency is a serious problem. This may occurs on static members which crosses different classes (Initializer of an instance field has much more limitations than static fileds).

Maybe the auto infering can be applied with some limitations, actually the most useful scene is just initialize an field with an default value like:

private var level = 0;

[thomaslevesque]

I would like this feature, but only for private members. For public members, I think it's better to be explicit; otherwise you can easily change the type of a member without realizing it, breaking compatibility with client code.

[paulomorgado]

All discussions around this, inevitable, come to that, @thomaslevesque. Although theoretically nothing prevents it to be public, the amount of work required by the compiler and the dangers involved.

Being one of those that said "I'll never use that" when var was presented and now use it all the time, I would use this.

[gafter]

We are now taking language feature discussion on https://github.com/dotnet/csharplang for C# specific issues, https://github.com/dotnet/vblang for VB-specific features, and https://github.com/dotnet/csharplang for features that affect both languages.