-
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
Pattern matching scope #2329
Comments
@VBAndCs |
It was an explicit design decision based on feedback on using the feature:
It can't be "changed", that would break existing code. |
Feel free to fork the repo and build your own compiler. |
You can't have it fixed. The decision was made and that's the way the language now works. Changing it would not only break a lot of code, it would deeply upset many users that want it to work in this "broken" fashion. |
Could you please do a developer survey b4 taking such exotic decisions that breaks the standard expected of millions of developers?
object o = 1;
if (o is string s)
{
}
Console.WriteLine(s); so, there is no code that can be broken, and defiantly this is a bug in defining the scope that should be fixed. |
No, it's not a bug, and you not liking the behavior doesn't make it a bug. This behavior is not going to change. End of story. |
if (!(o is string s))
return;
Console.Writeline(s); There must be thousands upon thousands of lines of code relying on this behaviour. It cannot be 'fixed'. |
No, the LDM makes the decisions. They posted their findings on Github and there was a discussion on the subject, which did result in some minor modifications. Lots of people didn't like it, myself included. But it avoided a lot of additional and unnecessary work to come up with more language features in order to expose those variables in the many cases where the developer would want to. This repo is not a democracy. The LDM are the ultimate and final arbiters to the evolution of this language.
Assuming that the LDM did want to change it (and they don't) it would still break pretty much all code using pattern variables in |
As I said, this will not break any significant code if any code at all.
|
You don't make that determination.
My opinion. |
So, why do we give feedback here? |
You give feedback before a feature has shipped. Not afterwards. |
The LDM does take feedback into consideration, but this repo is only one (relatively small) avenue for that feedback. It was user feedback here that made the LDM decide to walkback their original decision regarding this scope where it came to But once a feature has shipped based on explicit design choices the likelihood that the feature will be changed approaches nil, especially if it will break code written using that feature in a prescribed manner. I would recommend that if you want to have a discussion on the design process that Gitter would be the appropriate venue. |
@YairHalberstadt |
@VBAndCs |
Some wraparound for the sake of copy-paste: {
if (num.m_value is byte n)
return new Number(n + value);
}
{
if (num.m_value is sbyte n)
return new Number(n + value);
}
{
if (num.m_value is short n)
return new Number(n + value);
}
{
if (num.m_value is ushort n)
return new Number(n + value);
}
{
if (num.m_value is int n)
return new Number(n + (long)value);
}
{
if (num.m_value is uint n)
return new Number(n + (long)value);
}
{
if (num.m_value is long n)
return new Number(n + (decimal)value);
}
{
if (num.m_value is ulong n)
return new Number(n + (decimal)value);
}
{
if (num.m_value is float n)
{
var d9 = (double)value;
if (n > float.MaxValue - d9)
return new Number(n + d9);
return new Number(n + value);
}
}
{
if (num.m_value is double n)
return new Number(n + value);
}
{
var n = Convert.ToDecimal(num.m_value);
var d = (double)n;
if (value > maxDecimal - d)
return new Number(d + value);
return new Number(n + value);
}
} |
This is absolutely not true.
I would highly recommend following that advice. |
CSharplang is not a feedback site for features that have shipped and have been in the wild for this long. You can propose changes you'd like to see. However, the proposal should be fully fleshed out, and should address things like the potential for breaking changes. This repo is not for general gripes, or questions about how things are done. If you want to do either of those, please use gitter.im/dotnet/csharplang. Note: i was the LDM member who pushed for and got this scoping done as part of the pattern work we did. I have a lot of experience in this area. I can verify that it's practically impossible this would change. |
May God forgive you :) |
For what?
Examples were given in the thread. For example, the "guard pattern": if (!(foo is string s))
{
return;
}
// use 's' here. -- Note: I'm also working on a proposal where you can write the above as: if !(foo is string s)
{
return;
}
// use 's' here. |
if (!(foo is string s))
{
return;
}
// use 's' here. Is the twisted way to do this: if (foo is string s)
{
// use 's' here.
}
return; I don't see this as areal need to violate the scoping standards. |
yes.
You just identified the reason about why it was important to be done. There is no violation here as there is no scoping standard for patterns. We got to define whatever it was. By definition it's not a violation because this is the scoping standard. |
Why pattern matching variable scope goes is the outer scope, while it is the inner scope in other blocks like for loop?
This inconsistency is confusing, and makes coding harder in some cases like this:
all n1 to n11 vars are not needed ouside if scope, and it would be faster to copy-paste code directly using the same var name!
So, why did C# take this design decision that is inconstant with other block scopes, and can this be fixed?
The text was updated successfully, but these errors were encountered: