Default parameters and reflection: if ParameterInfo.IsOptional then is DefaultValue always reliable?

Question

I'm looking at how ParameterInfo.IsOptional is defined (I'm adding default parameter support to an internal IOC framework), and it seems to me that, when true, there is no guarantee that ParameterInfo.DefaultValue (or indeed ParameterInfo.RawDefaultValue) are actually the default values that are to be applied.

If you look at the MSDN example given for IsOptional, it seems possible in IL to define a parameter that is optional but for which no default is supplied (given that the ParameterAttributes.HasDefault must be explicitly supplied). I.e. potentially leading to a situation that a parameter type is, say, Int32, ParameterInfo.IsOptional is true, but ParameterInfo.DefaultValue is null.

My language is C#, therefore I can work on what that compiler will do. Based on that I can have a simple test as follows (parameter here is a ParameterInfo instance, and the method is meant to return an instance to be used as the runtime argument for the parameter):

if(no_config_value)
{
  if(!parameter.IsOptional) throw new InvalidOperationException();
  //it's optional, so read the Default
  return parameter.DefaultValue;
}
else
  return current_method_for_getting_value();

But I'm thinking that some languages (and I want to get this right at the IL-level, rather than just based on what one particular compiler does) can place the onus on the caller to determine the default value to be used, if so, a default(parameter.ParameterType) would need to be in order.

This is where it gets a little more interesting, because DefaultValue is, apparently DBNull.Value (according to the documentation for RawValue) if there is no default. Which is no good if the parameter is of type object and IsOptional==true!

Having done a bit more digging, I'm hopeful that the reliable way to solve this is to physically read the ParameterInfo.Attributes member, reading the bitflags individually first to check for ParameterAttributes.Optional and then check for ParameterAttributes.Default. Only if both are present, then reading ParameterInfo.DefaultValue will be correct.

I'm going to start coding and writing tests around this, but I'm asking in the hope that there's someone with more IL knowledge that can confirm my suspicions and hopefully confirm that this'll be correct for any IL-based language (thus avoiding the need to mock up loads of libraries in different languages!).

Andras Zoltan · Accepted Answer · 2012-04-03T13:55:55.683

The short answer to my question is no - just because IsOptional is true doesn't mean that DefaultValue will actually contain the real default. My suppositions further down in the question text were correct (and the .Net documentation does kinda explain this, in a round-about way). In essence, if a default exists, then the caller should use it, otherwise the caller should provide it's own default. The parameter's Attributes are used to figure out if a default exists.

This is what I've done.

Assume the following method exists:

/* wrapper around a generic FastDefault<T>() that returns default(T) */
public object FastDefault(Type t) { /*elided*/ }

And then given a particular parameter and Dictionary of supplied argument values (from configuration):

public object GetParameterValue(ParameterInfo p, IDictionary<string, object> args)
{
  /* null checks on p and args elided - args can be empty though */
  object argValue = null;
  if(args.TryGetValue(p.Name, out argValue))
    return argValue;
  else if(p.IsOptional)
  {
    //now check to see if a default is supplied in the IL with the method
    if((p.Attributes & ParameterAttributes.HasDefault) == 
        ParameterAttributes.HasDefault)
      return p.DefaultValue;  //use the supplied default
    else
      return FastDefault(p.ParameterType); //use the FastDefault method
  }
  else  //parameter requires an argument - throw an exception
    throw new InvalidOperationException("Parameter requires an argument");
}

I've then tested this logic on constructors and methods written like this:

public class Test
{
  public readonly string Message;
  public Test(string message = "hello") { Message = message; }
}

I.E, where a default is supplied in addition to the parameter being optional (the program correctly falls into the branch which reaches for ParameterInfo.DefaultValue).

Then, in answer to another part of my question, I realised that in C# 4 we can use the OptionalAttribute to produce an optional parameter with no default:

public class Test2
{
  public readonly string Message;
  public Test2([OptionalAttribute]string message) { Message = message; }
}

Again, the program correctly falls into the branch which executes the FastDefault method.

(In this case C# too will use the type's default as the argument for this parameter)

I think that covers it all - it's working nicely on everything I've tried (I have had fun trying to get overload resolution feeling correct as my IOC system always uses the equivalent of named arguments - but the C# 4 spec helped there).

Well not all languages require that you specify a default value in the function signature when declaring an optional parameter. I'm no expert, but it appears that in the case of F#, default values are applied within the function body - the benefit of which being that you can keep defaults consistent as you deploy new versions of assemblies (whereas with the C# and VB model, you can compile a library with a different default today, but assemblies compiled against yesterday's version will still send the old default). The F# Docs are [here](http://msdn.microsoft.com/en-gb/library/dd233213.aspx) — Andras Zoltan, Apr 24 '13 at 08:45
...So the F# example gives us a good pattern for why you'd use the `[Optional]` pattern instead of `int p1 = 0` in C#: possibly because you always expect the default to be the default for the type, and that you're then going to apply another default in the function body anyway. — Andras Zoltan, Apr 24 '13 at 08:47
By the way, `HasDefaultValue` crashes if the parameter is of type `System.DateTime`. This seems to be a bug in the .NET implementation. See https://github.com/dotnet/corefx/issues/12338 — Pierre Arnaud, Oct 04 '16 at 06:24
That's interesting @pierre - I'm using code just like this in my IOC container, Rezolver (on github, Dev branch is most up to date at the mo), and hadn't noticed that bug yet. I'll be sure to try and replicate so I can have the case covered for when they fix it :) — Andras Zoltan, Oct 06 '16 at 12:27

nawfal · Answer 2 · 2013-04-24T19:21:01.493

As you stated, there is a difference and is not reliable. Well, .NET 4.5 has HasDefaultValue, which checks if a parameter is optional (IsOptional) as well has a default value (DefaultValue) - same as

(p.Attributes & ParameterAttributes.HasDefault) == ParameterAttributes.HasDefault

in versions earlier. That should be the correct approach. Another approach is replacing the invalid default value depending on what the invalid value is in such cases (when parameter is not optional and when parameter is optional but without default value). For eg, you could just do:

if(p.DefaultValue != DBNull.Value)
{
    if(p.DefaultValue != Type.Missing)
        return p.DefaultValue;  //use the supplied default
    else
        return FastDefault(p.ParameterType); //use the FastDefault method
}
else  //parameter requires an argument - throw an exception
    throw new InvalidOperationException("Parameter requires an argument");

This works because p.DefaultValue is DBNull when parameter is not optional and Type.Missing when optional parameter but not supplied with default value.

Since this is undocumented, I dont recommend it. Better would be to replace p.DefaultValue != DBNull.Value with p.IsOptional. Even better would be to replace p.DefaultValue != Type.Missing with what you already answered: (p.Attributes & ParameterAttributes.HasDefault) == ParameterAttributes.HasDefault

Default parameters and reflection: if ParameterInfo.IsOptional then is DefaultValue always reliable?

2 Answers2

Linked