Roslyn: Proposal: Allow multiple conditions and variable declaration inside the if condition

[DerpMcDerp]

C# should allow a ; separator inside the if condition which acts as a lower-precedence && operator:

``` C#
if (a || b; c; d)

// ==>

if ((a || b) && c && d)

except that variable declarations should be allowed (and are used for side-effects and __NOT__ the value it evaluates to):

``` C#
if (whatever) {
    asdf;
} else if (a; var b = foo();/*b's scope begins here*/ b.asdf < 30) {
    blah(b);
    // b's scope ends here
} else {
    bleh;
}

// Equivalent to this pseudo-code (except the scope of b is extended).
// Notice that "var b = foo()" is only used for side effects ==>

if (whatever) {
    asdf;
} else if (a && (var b = foo(); true) && b.asdf < 30) {
    blah(b);
} else {
    bleh;
}

As a special case, the scope of variables should be extended to the entire if statement AST chain when they appear at the beginning:

``` C#
if (whatever) {
asdf;
} else if (
int a = 0; // a's scope begins here
int b; // b's scope begins here
int.TryParse("10", out b) && a >= 0 && b == 10;
int c = 0 // c's scope begins here
{
blah;
// c's scope ends here
} else {
// C#'s flow analysis statically determines that b is guaranteed to
// be initialized by this point:
bleh(b);
// a and b's scope end here since they appeared at the beginning
}

And just to make it explicit:

``` C#
// error: must contain at least 1 non-declaration expression
if (var a = true; var b = true) { blah; }

// error: expression can't be empty
if (true; ; true) { blah; }
if (;true) { blah; }
if () { blah; }
if (;) { blah; }

if (int a = 1; true; int b = 2) {
// ok:
    b = 3;
} else {
// ok:
    a = 4;
// error: b is not in scope
// (it doesn't matter if the expression to the left of the
// declaration was a constant boolean expression)
    b = 5;
}

// ok: optional trailing semi-colon is allowed
if (true; true;) { blah; }
if (true;) { blah; }

As prior art, Haskell's list comprehension notation somewhat resembles the above.

[DerpMcDerp]

This also can be extended to cover while loops as well:

``` C#
while (int a; foo == 3; bar == 4) {
}

// ==>

while (true) {
int a;
if (!(foo == 3)) break;
if (!(bar == 4)) break;
}
```

[HaloFour]

I don't see the reason for adding a new Boolean operator like this. You can already affect the precedence of Boolean operations via parenthesis. What's next, new flavors of the different mathematic operators just to affect their precedence?

Beyond that, this just smells like an awkward form of sequence expressions which is already proposed at #6182, although in that proposal any declared variables don't escape the expression regardless of where it is used.

[tumtumtum]

I think it's better to have a constant let on the outside that makes things more readable:

let someReallyClearReason = a && { var b = foo(); b.asdf < 30 };

if (someReallyClearReason)
{
}

[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 https://github.com/dotnet/roslyn/issues/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.