optional/null-able OUT parameter in C#

Question

I have a method that has several overrides. In one of the more expanded overrides, I want to return an OUT parameter but not in my simpler overrides. For example:

public bool IsPossible(string param1, int param2)
public bool IsPossible(string param1, int param2, out bool param3)

The way I am currently achieving this, is like so:

public bool IsPossible(string param1, int param2) {
    bool temp;
    return IsPossible(param1, param2, out temp);
}

Is there a better way to achieve this? Can I (or should I) use a null-able out parameter?

Tay

Answer 1

That looks fine to me. A out cannot be optional for technical reasons (it needs to point to a valid instance).

Delcine

Having a hard time believing the reason for not supporting this is technical more than marketing priorities. Seems the compiler could just create a temp location just as your example--and also for Refs by init'ing with Default(T). Notably, "out/ref (inout)" arguments are supported in SQL Server. – Excellent

It's worth to mention, that in C# 7.0 you can use Discards with Underscore sign. Read more here: https://mcmap.net/q/217965/-c-7-underscore-_-amp-star-in-out-variable – Optimist

VB.net does it. C# should automatically allow out/ref to be optional, and fill in a dummy variable when needed in the background. – Hamster

Answer 2

Since C# 7.0 you can pass a Discard (_) into the method:

return IsPossible(param1, param2, out _);

See: https://learn.microsoft.com/en-us/dotnet/csharp/discards

Milt

Good answer, but you forgot to write out return IsPossible(param1, param2, out _); – Irish

Thanks. Amended my answer – Milt

Answer 3

OP:

Can I (or should I) use a null-able out parameter?

A nullable out parameter won't do you much good. This:

public bool IsPossible( string param1, int param2, out bool? param3 )
{
  ...
}

doesn't make param3 optional. It changes the semantics of what param3 is. A bool? (aka Nullable<bool>) widens the domain of param3 from 2 values ( true and false ) to 3, adding a third value (null), usually interpreted as missing/unknown. The caller still must supply all three arguments.

Overloading IsPossible() by providing an overload -- the "don't care" scenario -- that discards the reference parameter is the proper solution.

Dixiedixieland

Answer 4

A 'ref' or 'out' parameter cannot have a default value.

The way you've done it is just fine. Sorry, no silver bullet.

Dia

Answer 5

Personally I think it is fine "as is". Another approach, though, is to return a composite return value (perhaps an immutable struct with 2 properties); that avoids the fact that some people avoid out. I am not one of those people :p

Re the question; indeed, out/ref can't be optional.

If you wanted to get unnecessarily fancy you could give the conposite return-type a conversion to bool to allow implicit if tests.

Whaling

Answer 6

Yes, Nullable variables are great. You would then do something like this.

public bool? IsPossible(string param1, int param2);

var ans = IsPossible("Parm1", 1);
if (ans.HasValue)
{
   //working.
 }

Amalee

I don't find this API style hugely obvious to the caller, personally. Subjective, though. – Whaling

What do you mean obvoius to the caller? – Amalee

well, for starters - there were previously 4 possible outcomes; there are now 3; what are they equivalent of, etc? what does it mean for IsPossible to be null? vs non-null but false? presumable true means "yes it is possible", but the other two are less clear-cut to me. – Whaling

Answer 7

Very old question. Anyway, there is another possibility. I do like @aaroncatlin 's answer about discarded variables.

But suppose the 3rd parameter is a byte[] and the caller optionally wants to return a huge number of bytes... Usually this construct is used by native API's.

So, if the callee expects the possibility of getting a null reference, we can pass a null as 3rd parameter from an unsafe block like this:

public unsafe bool IsPossible(string param1, int param2) {
    return IsPossible(param1, param2, out *(bool*)null);
}

In this case useless. But in case of optional byte[] it does make sense.

Henricks