Proposal: syntax for null-propagating arguments in method calls

[contextfree]

Before C# 6, I've often been tempted to add an IfNotNull<T>(this object x, Func<object, T> f) or similar
extension method for short-circuiting null-propagating execution. I'd expected that C# 6's ?. operator
would "solve the problem" and remove this temptation, but what I've found in practice is that it's more
common to want to pass a maybe-null object into a method that doesn't accept null arguments, rather than accessing a member on a maybe-null object.

An approach I think could nicely complement ?. for this case would be to extend method call syntax to
allow each argument to be marked as null-propagating:

SomeMethod(?a, b, ?c, ...)

which would return null if any of the arguments prefixed with ? are null, and evaluate as usual otherwise. (so returns T? if the return type T is a value type.)

(unsure about: should the first null ?arg encountered short-circuit evaluation of subsequent arguments?)

I like this syntax because of the feeling of symmetry or duality with ?. - in obj?.Member, the required data flows from left to right, and the ? is like a guard that intercepts null values before they can reach the ., and changes the evaluation of the overall expression. In Method(?arg) , the data flows from right to left, and the ? intercepts the null value before it reaches the (, and changes the overall evaluation. So by covering both cases or directions, I think the null-propagation functionality overall would feel more cohesive and less surprising.

[HaloFour]

See: dotnet/roslyn#5961

[contextfree]

Thanks, I hadn't seen that.

That proposal is much more comprehensive and consistent, at the cost of taking on extra ontological baggage (poison values, etc.), which seems hard to justify because null propagation is inherently kind of hacky. This is meant to cover what I'll vainly guess are a strong majority of null propagation use cases, but stay in the spirit of ?. as a neat little convenience feature - it's a new "local" feature of method calls, not a new operator or a new kind of value.

I also think the prefix ?x syntax could mitigate some of the concerns raised in that thread about the ?s blending in, etc. - the ? becomes the first thing you see in an argument position, and looks weird, reinforcing that what follows it is not just a different argument, but "differently an argument".

[HaloFour]

@contextfree

My opinion is that the primary issues identified in that Roslyn proposal are the same as exist here in that it is some operator applied to an argument expression that alters the behavior of the parent expression, even if that is just limited to a method call.

[alrz]

Using #176 you could do:

object M() {
  return SomeMethod(a ?? return null, b, c ?? return null, ...)
}

You can already do M(a ?? throw ...) but it's only useful when you want to, well, null check and throw.

[alrz]

Maybe we could have obj?? as a shortcut for obj ?? return default or obj ?? return.

[svick]

Maybe we could have obj?? as a shortcut for obj ?? return default or obj ?? return.

I don't think that's a good idea. Returning from a method is too big of a side-effect to be hidden inside just two fairly inconspicuous characters.

[alrz]

@svick,

I agree. just for reference, Rust's ? operator works this way (though that's bound to Result type and error handling which afaik was meant to be relaxed to work with other result-like types like Option).