null should be supplied for missing values - not an empty string

Consider:

class MyOptions
{
    public MyOptions(string foo)
    {
    }

    [Option(Required=false)]
    public string Foo {get;}
}

If I don’t specify foo on the command line, it’s going to be provided as an empty string ("") in the constructor. It really should be null instead, both logically and to differentiate against an actual empty string parameter.

[vesuvian]

Google landed me here because I’m running into the same Enumerable null default problem as Adhara3.

My two cents: I think null is descriptive in saying “this option was not used” rather than “the user provided no parameters for this option”. Checking for null is totally safe, whereas checking for .Any() could show warnings about multiple enumeration.

Providing a Default parameter and then not obeying that is really unhelpful. It would be helpful if an exception was thrown for null because it at least clarifies the intended behaviour, but I’d prefer if null was handled properly and an exception only be thrown if the property type is non-nullable.

[ericnewton76]

I believe the change falls in line with least surprise principal. I tried to investigate when a string.empty got substituted for null in the first place and couldnt find a logical reason why. Perhaps its related to F#?

This pull request seems fine to me. We’ll see if a rash of F# guys come beating down our doors 😄 We’ll point them in this direction and to explain how to somehow manage F# compliance with the existing CLS compliant languages

I watched a demo about domain driven design with F# and there was some (initially contrived) decently good reasons for using F# over others.