Allow var use with optional arguments.

[rawlinson]

Optional argument declarations can get quite long, especially when using enums or generic types. Allowing the use of var would shorten the declarations making the code more readable and reduce redundancy. Compare:

void DoThis(PartialResultProcessing processing = PartialResultProcessing.NoPartialResultSupport);
void DoThis(var processing = PartialResultProcessing.NoPartialResultSupport);

[VisualMelon]

This is closely related to the idea of allowing var fields and auto properties, which I recall has been rejected in the past (but I can't find a reference). I can't recall the reasons it was rejected either, but they should certainly be dug up and looked at.

Given the optional parameters are (currently) required to be constants, one could perhaps argue that the type will always be obvious, but can still be a function of other code. Note that enum values are not constants; PartialResultProcessing.NoPartialResultSupport would have to be an explicitly const field. If this const (but clearly not constant) field was to change type then it would change the API.

The benefit of shortening the type (when the default value will no doubt be longer) in a select number of cases seems minimal, and also opens up some opportunity for misuse/abuse when it is by no means warranted; duly, I would be disinclined to support this proposal presently.

[rawlinson]

This is also linked to #354 and #764, which would potentially allow the following, respectively:

void DoThis(PartialResultProcessing processing = NoPartialResultSupport);
void DoThis(PartialResultProcessing processing = .NoPartialResultSupport);

Though both only apply to enums, although the second could be expanded to general member access, allowing, for example, the following:

void DoThis(string str = .Empty);

[VisualMelon]

I believe that allowing enums would require a significant change in how default parameters are implemented; I believe they essentially bake constants into the assembly at the moment, but enums can be exposed by an API and change, so I presume that would require some effort.

[DavidArno]

@VisualMelon,

See "Why no var on fields?" by Eric Lippert for a good description of why var fields are challenging.

Also, see #601 for [my] proposal for allowing them and the resultant discussion.

[VisualMelon]

@DavidArno thank you kindly: I knew it had been discussed somewhere...

Clearly a number of the issues presented in those 2 resources do apply; though, the situation it not quite 'as bad', as these parameters are the 'end of the chain' of misery. I do think that the benefit (if there is any) of this proposal is too minimal to justify the issues associated with maintaining an implicitly declared external API (ignoring the cost-of-implementation concern).

[rawlinson]

So it seems using var on the left-hand side is tricky, both in terms of implementation and in having an implicitly declared API.

One option that I don't think has been suggested yet is to also allow var on the right-hand side, so that the following would be equivalent:

var someMap = new Dictionary<string, Func<int>>();
Dictionary<string, Func<int>> someMap = new var();

This would address this issue as well as ones such as #601 and #100, while hopefully being implementable and leaving the API explicit.
In this case it would allow:

void DoThis(PartialResultProcessing processing = var.NoPartialResultSupport);

and also potentially address #354/#764:

type.GetProperties(var.Public | var.Static);
...
if (myEnumTypeValue == var.SomeOtherValue || myEnumTypeValue == var.SomeValue)
{
...

This change would be semantically consistent with vars existing use, in that it would still refer to the current implied type.

[yaakov-h]

@rawlinson How about #100?

Using var would not be consistent with existing use, because it is currently a declaration, not an accessor.

[rawlinson]

@yaakov-h #100 does not address this issue as it only targets the use of new, and so has no bearing on assigning a none-zero enum or a field (String.Empty), etc.

Expanding the use of var would, however, remove the need for #100.

[HaloFour]

I much prefer the syntax suggested by #321. When not ambiguous you can simply omit the name of the enum:

void DoThis(PartialResultProcessing processing = NoPartialResultSupport);
...
type.GetProperties(Public | Static);
...
if (myEnumTypeValue == SomeOtherValue || myEnumTypeValue == SomeValue)

[rawlinson]

@HaloFour I generally prefer things to be qualified and think #321 would add ambiguity, if not for the compiler then for the reader. What would happen with the following:

BindingFlags Public = BindingFlags.Public | BindingFlags.Static;
type.GetProperties(Public | FlattenHierarchy);

I don't see a way of resolving it that wouldn't require me to look closely as each case where the type is omitted. Using var would remove such amiguities.

Also, what about field access, should all member names be allowed to be 'shortcutted'? String s = Empty?

I also dislike #100, the syntax looks too close to tuples for me. Again, using var would make the intent clear.

var removes the redundancy whilst maintaing clear intent and only requires an increase in scope of an existing keyword. It also has precedence in the new parameterless default , which would be equivalent to default(var). #100, #321, etc. would require two completely separate changes to the language.

I think a new issue should be raised to propose the change to var.

[HaloFour]

@rawlinson

Just to note, you can already shorten enum member access via using static, and that does exihibit the same ambiguity potential as #321:

using System;
using System.Reflection;
using static System.Reflection.BindingFlags;

public class C {
    public void M() {
        Type type = typeof(C);
        BindingFlags Public = BindingFlags.Public | BindingFlags.Static;
        type.GetProperties(Public | FlattenHierarchy);
    }
}

[rawlinson]

@HaloFour In that case the behaviour is opt-in. And I am tempted to propose removing using static from the language, or requiring a license for its use!

[rawlinson]

I have added a new issue for the new proposed behaviour: #1063.

[jnm2]

In that case the behaviour is opt-in. And I am tempted to propose removing using static from the language, or requiring a license for its use!

Related: https://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html