[Proposal]: Allow for 'when' patterns on function parameters.

[thargol1]

Allow for 'when' patterns on function parameters.

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Having patterns on function parameters would allow for functions to be split in several independent blocks of code.

Example

A contrived example for clarity:

public string Report(int number) when number < 0
{
	return "I'm sorry you're in debt.";
}

public string Report(int number)
{
	return "All clear.";
}

The compiler could generate the following code with a dispatcher for this

// dispatcher
public string Report(int number)
{
	if (number < 0) return Report_@1(number);
	return Report_@2(number);
}

internal string Report_@1(int number)
{
	return "I'm sorry you're in debt.";
}

internal string Report_@2(int number)
{
	return "All clear.";
}

Motivation

This would allow for the following scenarios:

• If the compiler can prove the parameters always meet the condition it can generate code that bypasses the dispatcher, making for faster code.
• If the compiler can prove a specific version is never called and it's 'private' or 'internal' it can omit it from the generated dispatcher-code and remove the version entirely.

For developers it could mean:

• Clearer code with less indentation.
• More expressive function definitions.
• Separation of concerns on the micro level, e.g. separation parameter validation from actual implementation.
• Better documentation, if the documentation generator is updated as well.

For the .Net runtime it could mean faster code, for example string.Equals(a, b, StringComparison.Ordinal) could jump directly to the ordinal compare code bypassing some checks if it's defined with something like this when a is not null and b is not null and comparison == StringComparison.Ordinal.

Drawbacks

One could consider this feature as 'helping the compiler'. In general developers should not help the compiler, it's smarter than most of them.

Alternatives

Don't implement this and just use existing code patterns.

Unresolved questions

Would this be limited to patterns or would expression also be allowed? The compiler would have an easier job proving patterns than expressions. On the other hand constant expressions calling constant functions can also be proven during compile time.

Use the when or the where keyword? In my opinion it should be the when keyword as this feature is similar to switch statements/expressions.

Would this be allowed for virtual functions? Object inheritance can complicate this a lot.

Compatibility

As the generated dispatcher function is backward compatible with existing C# this feature would not break existing code bases.

More examples

class X : IEquatable<X>
{
	public string Y {get; private set;}

	public bool Equals(X? other) when other is null => false;
	public bool Equals(X other) => Y.Equals(other.Y); // Can we leave out the question mark after X, or would that change the signature?

	public void UpdateY(string? value) when value is null
	{
		throw new ArgumentNullException(nameof(value));
	} 

	public void UpdateY(string value) when value is { Length < 3}
	{
		throw new ArgumentException("Too short", nameof(value));
	} 

	public void UpdateY(string value) => y = value;

	void Demo(object param) when param is SqlConnection
	{
		//...
	}

	void Demo(object param) when param is SqlTransaction
	{
		//...
	}
}

[HaloFour]

See:

#1548
#1468
dotnet/roslyn#955

[thargol1]

Hmm, I did search for existing proposals. I must have used the wrong searchterms.

I think my 'Motivation' and suggested implementation' is better than in #1548 and #1468.

The discussion boils down to the major argument that you can do the same in less code with switch statements or switch expressions. And I won't contest that, but I would like to know if my motivation for this proposal makes any sense and merits reconsideration?

[HaloFour]

@thargol1

I think the problems identified in those other discussions still hold. Overload resolution is entirely a compile-time concern in C#. The compiler determines which overload to call based on binding the types of the arguments and various rules about how they can be coerced or implicitly converted. A failure to match is caught at compile time. With this proposal (and the others) overload resolution has to be moved, at least in part, to runtime, via this "dispatcher". There is no longer a 1:1 mapping to the number of methods written to the number of methods emitted. Their lexical order in suddenly matters as it establishes the priority of the patterns, which doesn't really work well across partial types. And the lack of a match becomes a runtime exception vs. a compiler error.

As for the argument that it's less code, I don't see that. Considering that you have to repeat the signature each time for each of these "overloads" you're easily writing more code than if you had a series of if statements or a switch expression.

[thargol1]

I'll close this issue.

• My argument was not about less code, but clearer code. Which is by itself an opinionated topic. And my argument was about performance because the compiler can jump directly to a specific case if it can prove it based on the patterns and arguments.
• The 'dispatcher' is code you now write yourself, using if or switch statements, so in current code it's also run-time and not compile-time.
• If have no solution for the priority of patterns other than making all the patterns mutually exclusive.

[snow-jallen]

@thargol1 I completely concur that this opens a door to write clearer code. Guard clauses on functions in c# would be such a nice breath of fresh air. Yes, I can use a switch expression within a method, but if I can move that filter to the top of the method so I know for sure that method will only ever be called with certain values of parameters that lets me clean up the body of my method so much! I got a taste for that with elixir and now whenever I work in C# I find myself missing that ability.

[spydacarnage]

You could potentially use a source generator to add the dispatcher for you, based on an attribute?

[Dispatcher("number < 0")]
internal string Report_@1(int number)
{
	return "I'm sorry you're in debt.";
}

[Dispatcher]  // no parameter
internal string Report_@2(int number)
{
	return "All clear.";
}

[HaloFour]

And my argument was about performance because the compiler can jump directly to a specific case if it can prove it based on the patterns and arguments.

The CLR only permits overloads with different signatures based on the arity and type of the parameters. Patterns couldn't be a part of that signature, not without some kind of runtime changes to accompany this feature. The compiler would still be required to emit a single copy of that method with the dispatch code written within it, and there wouldn't be another method that consumers could call directly to skip that dispatch.

[AartBluestoke]

the devirtualization and redundant runtime code elimination code within the the JIT is getting better, i would imagine scenarios where the dispatch could be proven to go to a particular case and the intermediate function skipped.

[thargol1]

I think we have a misunderstanding about what I'm proposing. I can see it clearly in my mind, but I don't think I got the idea across very well.

In the example at the beginning, the programmer specifies 2 functions. The C# compiler emits 3 functions. One that I call the 'dispatcher' and thats gets called always if the compiler cannot not make a compile-time decision and the 2 original functions with a new unique name.

Use case 1:

const x = -1;
Report(x);

In this case the C# compiler can prove based on the pattern which function to call and emits a call to Report_@1, saving the execution of a compare.

Use case 2:

void Demo(int x)
{
    Report(x);
}

In this the compiler can most likely not prove which particular version to call and emits a call to Report.

So I do not see where run-time changes would be necessary as I propose this as a compile time feature and after the C# compiler is done with it, only classic backward compatible code remains.

If this gets implemented and used this contrived example code could skip 2 null checks. And the generated dispatcher function would not be slower than the current version of string.Equals.

string a = 'test';
string b = 'Test';
if (string.Equals(a,b))
{ ... }

I know these are micro optimisations and null checks and most compares are very fast, but every CPU cycle saved is a CPU cycle saved.

As for the order of patterns that remains an issue, so I was thinking:

• Patterns are mutually exclusive, if they are not the compiler either generates a warning that it cannot guarantee consistent code or it generates an error.
• One function without a pattern is allowed and always the last in the order.

So for example the example string.Equals you could have the patterns:

Equals(string a, string b) when a is null and b is null => true;
Equals(string a, string b) when a is null and b is not null => false;
Equals(string a, string b) when a is not null and b is null => false;
Equals(string a, string b) when a is not null and b is not null { ... }

And yes that can add up to a lot of typing code, but if it saves me a few milliseconds of execution time, I don't mind.

[HaloFour]

Even without runtime changes this amounts to moving some aspect of overload resolution to run-time (the dispatcher) vs compile time. This is something that team has expressed not being interested in.

Beyond that, I don't see how the performance benefits you describe would be practical. Those direct calls where the compiler would know enough information about the value to skip the dispatcher would be exceedingly rare. The vast majority of the time the compiler would have no idea of the potential ranges of values possible for a given variable. Given how complex patterns can be (especially with recursive patterns) there would be a massive amount of information to track, and that information would be lost at every boundary without massive changes to the type system to enable flowing that information between methods. And for that amount of effort the savings would be absolutely minuscule as those comparisons are quite cheap.

[CyrusNajmabadi]

Another way to put this is:

If the benefit here is a claimed performance benefit, then that performance benefit needs to be strongly demonstrated. That can be done by just showing the sort of code this would end up compiling down to and then measuring the performance of that code itself.

[thargol1]

My first test:

I made a copy from the reference source of Enumerable.FirstOrDefault.

Than I made a 'dispatcher' version of it:

public static TSource FirstOrDefault<TSource>(this IEnumerable<TSource> source)
{
	if (source is null) return FirstOrDefault_0(source); // pattern: source is null
	if (source is IList<TSource>) return FirstOrDefault_1(source); // pattern : source is IList<TSource>

        // no pattern
	using (IEnumerator<TSource> e = source.GetEnumerator())
	{
		if (e.MoveNext()) return e.Current;
	}
	return default(TSource);
}

public static TSource FirstOrDefault_0<TSource>(this IEnumerable<TSource> source)
{
	throw Error.ArgumentNull("source");
}

public static TSource FirstOrDefault_1<TSource>(this IEnumerable<TSource> source)
{
	var list = source as IList<TSource>;
	if (list.Count > 0) return list[0];
	return default;
}

There are the results:

Method	Mean	Error	StdDev	Ratio	RatioSD
'Original called with List'	7.680 ns	0.0660 ns	0.0551 ns	1.00	0.00
'Dispatcher called with List'	12.486 ns	0.0405 ns	0.0338 ns	1.63	0.01
'Direct call with List'	7.293 ns	0.0756 ns	0.0631 ns	0.95	0.01
'Original called with IEnumerable'	35.289 ns	0.3470 ns	0.3246 ns	4.59	0.06
'Dispatcher called with IEnumerable'	34.480 ns	0.4449 ns	0.4162 ns	4.48	0.06

Observations

• The direct call to FirstOrDefault_1 is consistent 4 to 5% faster.
• The dispatcher called with List<T> is consistent slower, but as the compiler has already null checks build in it can prove in most cases that the argument it's a non null IList and generate a direct call to FirstOrDefault_1.
• The dispatcher called with IEnumerable<T> is consistent a tiny bit faster. I do not have an explanation for this.

What are other good candidates to test this proposal with?