-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Champion "Expression variables in initializers" (15.7) #32
Comments
Handing off to @AlekseyTs to drive the LDM discussion. |
I'm struggling to find documentation about exactly what this change entails, as the links seems to go around in a circle and end up on this page that seems to tell me that nothing has been implemented, yet it is listed in the Visual Studio 15.3 release notes as released. Can anyone shed some light on this, or is it perhaps obvious to everyone but me what this change is about? |
See dotnet/roslyn#16270. With C# 7.3 in VS2017 v15.7 (thought not the .NET Core CLI tools or Visual Studio for Mac yet), the following code is now legal. Previously, they would trigger the compiler error CS8200. using System.Collections.Generic;
using System.Linq;
public class A
{
public A(int i)
{
}
public static int Magic = int.TryParse("123", out var i) ? i : 0;
}
public class B : A
{
public B(string s)
: base(int.TryParse(s, out var i) ? i : 0)
{
}
} This covers both constzuctor-initializers and field-initialisers. I'm not sure about query clauses, I haven't been able to find an example that used to cause a compiler error but now works. FWIW, the 2.7.0 compilers in SharpLab don't like the above just yet, but the master branch does. |
The following code is now legal in query clauses.
|
It seems that returns Will this work too? I.e., referring to the expression's variable?
|
See also dotnet/roslyn#16270
There are three contexts where out variable declarations and pattern matching variable declarations are not permitted today, in part because we did not decide what the scope should be. I propose we decide for each of these three contexts, and extend the language to permit declaration expressions in these contexts.
Constructor-initializers. The primary question is whether the scope of variables declared in a ctor-initializer extends to the constructor body or not. I propose that it should extend to the body.
Field initializers. The primary question is whether the scope of variables declared in the one equals-value-clause is in scope in subsequent equals-value-clauses of the same field declaration (when it declares more than one field). It is also possible to extend the scope to subsequent separate field declaration's initializers too, but I don't think that is likely to be approved by the LDM.
Query clauses. The primary question is what is the scope of variables declared in a query clause that is specified to be translated into the body of a lambda. One possible resolution is that its scope is just that expression of the clause.
The text was updated successfully, but these errors were encountered: