Proposal: allow "params" as a valid variable name outside of parameter definition

[DrLeh]

So many times I want to do var params = <something representing parameters> but I can't because params is a global keyword, instead of just a keyword in the context of a method signature.

There is some precedent for this, take value when in the context of a Property set, only then is value used as a keyword, in any other context you're free to name your variable that. I think the same should be true of params.

Example:

public void Process(params string[] strings)
{
    //represents valid parameters
    var params = strings.Where(x => !string.IsNullOrEmpty(s)); //currently has compiler error
}

[alrz]

I agree that it could be a contextual keyword since it's only allowed in a param list, but it's not different from other keywords that you might want to use to name things. That's why there's a escape character: @params.

[DavidArno]

Not only is it easily worked around with @params, but params is a terrible variable name. In your example, validParameters would be a better choice for example, removing the need for the comment.

[bondsbw]

outside of parameter definition

I'm not sure this restriction would be needed, I don't think it would cause ambiguity even in that situation:

public void Foo(Parameter[] params, params string[] strings) { ... }

public void Bar(params Parameter[] params) { ... }

// etc.

[CyrusNajmabadi]

There would def be no ambiguity. I raised this several years back with the LDM (effectively moving many keywords to be contextual keywords). The primary case for me was that i wanted to be able to use 'out' as a normal word. For example:

using (var in = GetInputStream())
using (var out = GetOutputStream())
{
     out.Write(Translate(in.Read()));
}

Sentiment back then was that it was nice to have keywords just be unambiguously keywords. However, as the language has moved forward and embraced (out of necessity) contextual keywords everywhere, we may be more open to relaxing things here.

--

But, again, the major concern is if this would limit our design space elsewhere. For example, say we decided we really wanted to be able to use 'out' somehow in an expression context. like "Foo(out)", today we don't have to worry about that breaking anything. But if "out" is just a contextual keyword, now there's an issue.

So, we've erred on keeping keywords keywords since there just doesn't seem to be enough value to warrant the work to make the contextual.

--

Also, from an impl perspective contextual keywords are a PITA. You have to have so much parsing goop to properly understand and handle the interpretations in a non-breaking manner. I've personally broken things here at least twice because it can be so tricky and to get totally right.

[DrLeh]

That makes a lot of sense, leaving it as a keyword for potential future use, since it's hard to introduce a new keyword without breaking a lot of things. I wasn't sure how easy it was to do contextual keywords, but I can see how it could get complicated. Thanks for your insight!

[chergey]

That doesn't change too much. Imho, we can always avoid wanting to use keywords as variable names.

[Thaina]

I don't oppose the idea. Agree that there is no ambiguity

But in my opinion. I prefer we should reserve an already reserved keyword for using it elsewhere in the future. So whenever we want to have any functionality that could reused the old keyword we could do it without concerning of breaking change