Skip to content
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

Why doesn't use an invalid name in discards? #27101

Closed
CreateAndInject opened this issue May 24, 2018 · 3 comments
Closed

Why doesn't use an invalid name in discards? #27101

CreateAndInject opened this issue May 24, 2018 · 3 comments
Labels
Area-Language Design Question Resolution-External The behavior lies outside the functionality covered by this repository

Comments

@CreateAndInject
Copy link

As we know, "_" is a valid name:

if (int.TryParse("123", out int a))
    Console.WriteLine(a);

if (int.TryParse("123", out int _))
    Console.WriteLine(_);

So, I think these 2 are both correct.

Why doesn't use an invalid name (such as * or #) instead of _?
like this:

if (int.TryParse("123", out int *))
{
//this time, nobody will try to use:
//Console.WriteLine(*);
}
@svick
Copy link
Contributor

svick commented May 24, 2018

This is documented in Language Design Meeting notes for 15 November 2016 (emphasis mine):

We got great feedback on "wildcards" at the MVP Summit, including changing its name to the term "discards", which is spreading in industry.

We are also encouraged to use _ as the discard character instead of *. It works better visually, and is what many other languages already use.

@HaloFour
Copy link

@CreateAndInject

This was a subject of a lot of debate and I still don't agree with the outcome, but that's where we are now.

#14794
#14832
#14862
dotnet/csharplang#1064

@sharwell
Copy link
Member

@CreateAndInject I believe the answers to your question(s) can be found in the links provided by @HaloFour. If you have additional questions, you can ask them in dotnot/csharplang. 😄

@sharwell sharwell added Resolution-External The behavior lies outside the functionality covered by this repository Question Area-Language Design labels May 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Language Design Question Resolution-External The behavior lies outside the functionality covered by this repository
Projects
None yet
Development

No branches or pull requests

4 participants