Support the use of var in more cases

[gafter]

@eamodio commented on Mon Apr 20 2015

Currently var can only be used in cases where the declaration and assignment are linked. It would be great (imo) if var could be used even if those statements weren't linked but was still verifiable by the compiler (not looking for dynamic here or anything like that).

This would be great for cases like the following silly example:

Before:

IQueryable<PersonViewModel> query;
if (SimpleQuery) 
{
    query = from p in Context.Query<Person> 
                 select new PersonViewModel { Person = p };
}
else
{
    query = from p in Context.Query<Person>
                 select new PersonViewModel { Person = p, Friends = p.Friends };
}

After:

var query;
if (SimpleQuery) 
{
    query = from p in Context.Query<Person> 
                 select new PersonViewModel { Person = p };
}
else
{
    query = from p in Context.Query<Person>
                 select new PersonViewModel { Person = p, Friends = p.Friends };
}

It would be even more awesome if the compiler could infer even more - maybe using some structural typing when generating the anonymous, like:

var query;
if (SimpleQuery) 
{
    query = from p in Context.Query<Person> 
                 select new { Person = p };
}
else
{
    query = from p in Context.Query<Person>
                 select new { Person = p, Friends = p.Friends };
}

---

@aluanhaddad commented on Wed Apr 22 2015

The example you provide can be easily simplified with the use of the ?: operator.

var query = from p in Context.Query<Person> 
            select SimpleQuery ? 
                new PersonViewModel { Person = p } :
                new PersonViewModel { Person = p, Friends = p.Friends };

That said there are cases where it could be useful, such as in try - catch - finally blocks, but it would have some unpleasant consequences. For instance, the type of the variable cannot be referred to until it has been assigned. Also, the type becomes path dependent so the compiler would need to do flow analysis to make sure that all possible assignments resolve to the same type.

---

@eamodio commented on Wed Apr 22 2015

Yeah - the example was certainly the most simple version and could be replaced with ?:, but you can imagine much more complex versions, try/catch as you mentioned, usings, multiple ifs, switch statements, etc.

Why couldn't the type of the variable be referred to? The variable isn't dynamic - it would still be statically known through some compiler magic ;) -- hopefully only needing limited flow analysis over what is currently done for var. And any case the compiler didn't want to support (because of complexity or whatnot) it could just issue an error that var couldn't be used in that case.

While I think the simple var case is nice, my guess the bang for the buck wouldn't necessarily pay off (but wanted to raise it as it would be nice and who knows might be easy). Though I think the really valuable feature would be "structural" typing with anonymous objects. That imo would be a huge win and isn't just syntactical sugar.

---

@aluanhaddad commented on Sat Apr 25 2015

@eamodio

To your first point:
Yes, there are indeed more cases than just try - catch - finally, an expression form of pattern matching would solve most of these issues (see below).

To your second point:
var does not need to use flow analysis as it currently stands. It simply infers the type of the variable as the type of whatever expression is on the right hand of the =. I agree it has nothing to do with dynamic typing. I was suggesting the flow analysis would be complex, especially for tools like intellisense.

To your third point:
I think some form of structural typing would be great. The current proposals for tuples, which are expected to have nameable components, might give just this functionality. Also, the proposal for pattern matching, which currently includes property pattern matching, would also benefit in this area.

---

@GeirGrusom commented on Mon Apr 27 2015

You can't use var with unsafe code either.

fixed (var* ptr = "abc")
{
  ptr[0] = 'A';
}

---

@GSPP commented on Sun Oct 25 2015

Also consider var on fields.

[jnm2]

-1 for the var x; syntax.

[DavidArno]

👍 for the idea of fields being able to use var.

👎 👎 👎 👎 👎 👎 👎 👎 👎 👎 👎 👎 👎 👎 👎 for the idea of the var query; syntax.

[gulshan]

Inferring type from multiple expressions for a mutable variable is not that feasible I guess.

[jnm2]

If it was totally feasible I'd be just as against it. There is great value to being able to understand a name in context with its type and value all in one place without scanning through the method body and it encourages code that is more self-documenting.

[mattwar]

On this surface it seems like this is not different than figuring out the return type of a statement lambda. However, since its a variable that can be referenced within the body of code itself, it becomes a bit more complicated.

Otherwise, I'm always in favor of more var.

[eduarddejong]

Because I also opened a discussion about it (see #6200) and this subject still keeps me thinking, I would like to add something additional:

The Rust programming language already supports this feature.
The "var" keyword of Rust is let. In Rust it's totally possible to type let variable_name; and get everything filled in by later code. And everything works very smooth, natural and quickly.

Rust's type inference is way more powerful than C#'s in soo many aspects. Rust infers both in forward and backward directions, and also subparts of types (you can often also fill in underscores for generic parameters, for example when you need to create a Vec but you want to have the generic type inferred), all saving you from tons of typing.
And while this is true, you also have the Rust Analyzer, at least in VS Code, it shows all types in labels for you behind the variable names, such that you can still quickly see everything.

I am not saying that C# should completely follow all this, but at least it might be a good idea to look around a bit more how other languages solve things here, to see what's possible.
To be honest, I am also still very explicit with many things in C# code, but I think it's a good to keep questioning things.