Generic Argument Expressions And Method Constraints

[ZacharyPatten]

Static Generic Argument Expressions And Method Constraints

EDIT: I originally thought this would only work with static (non capturing) expressions, but it should work with captures too, so I crossed out "static".

Overview

I think it is possible to allow static expressions and static methods to be used as generic arguments in C#. This would allow for more optimized functional programming without having to wrap functions inside custom struct types. Here is an example:

Overview Code Snippet 1 [click to expand]

using System;

namespace Example
{
	public static class Program
	{
		public static void Main()
		{
			PerformAction<int, a => Console.Write(a)>(7);
		}

		public static void PerformAction<T, Action>(T a)
			where Action : [void method(T)]
		{
			Action(a);
		}
	}
}

The { a => Console.Write(a) } expression in the above code snippet could be compiled into a seperate static method like so:

Overview Code Snippet 2 [click to expand]

using System;

namespace Example
{
	public static class Program
	{
		public static void Main()
		{
			PerformAction<int, ConsoleWrite>(7);
		}

		public static void ConsoleWrite(int a) => Console.Write(a);

		public static void PerformAction<T, Action>(T a)
			where Action : [void method(T)]
		{
			Action(a);
		}
	}
}

From there, the ConsoleWrite method could be wrapped inside a compiler generated struct that would be used as the final generic parameter:

Overview Code Snippet 3 [click to expand]

using System;

namespace Example
{
	public static class Program
	{
		public static void Main()
		{
			PerformAction<int, g__ConsoleWrite_1>(7);
		}

		public interface IAction<A>
		{
			void Do(A a);
		}

		public struct g__ConsoleWrite_1 : IAction<int>
		{
			public void Do(int a) => ConsoleWrite(a);
		}

		public static void ConsoleWrite(int a) => Console.Write(a);

		public static void PerformAction<T, Action>(T a)
			where Action : struct, IAction<T>
		{
			Action action = default;
			action.Do(a);
		}
	}
}

Aside from syntax changes, there would also need to be additional interface types IAction<T>, IFunction<T>, IAction1Ref<T>, IAction<T, T>, IFunction<T, T>, etc. for the mapping between the generic parameter and the compiler generated struct.

EDIT: Rather than adding interfaces, it might be possible/better for the compiler to generate both the interfaces and the structs.

Motivation

This is more optimized that the current standard delegate syntax if the function is static, because it would not result in a delegate type at runtime. It would be resolved at compile time and potentially inlined by the JIT. Since no delegate would exist at runtime, there would be no heap allocation for it. Here are some testing results using Benchmark.NET:

Benchmark 1 Code [click to expand]

using System;
using System.Linq.Expressions;
using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

namespace Benchmarks
{
	public class Benchmarks
	{
		int temp;
		int _1;
		int _2;
		int _3;
		int _4;
		int _5;

		[GlobalSetup]
		public void Setup()
		{
			_1 = 1;
			_2 = 2;
			_3 = 3;
			_4 = 4;
			_5 = 5;
		}

		[Benchmark]
		public void IntegerAdd()
		{
			temp = _1 + _1;
			temp = _2 + _2;
			temp = _3 + _3;
			temp = _4 + _4;
			temp = _5 + _5;
		}

		[Benchmark]
		public void IntegerAddStructWithAggressiveInlining()
		{
			temp = DoWithAggressiveInlining<int, g__AdditionWithAggressiveInlining_1>(_1, _1);
			temp = DoWithAggressiveInlining<int, g__AdditionWithAggressiveInlining_1>(_2, _2);
			temp = DoWithAggressiveInlining<int, g__AdditionWithAggressiveInlining_1>(_3, _3);
			temp = DoWithAggressiveInlining<int, g__AdditionWithAggressiveInlining_1>(_4, _4);
			temp = DoWithAggressiveInlining<int, g__AdditionWithAggressiveInlining_1>(_5, _5);
		}

		[Benchmark]
		public void IntegerAddLinqWithAggressiveInlining()
		{
			temp = AdditionWithAggressiveInlining(_1, _1);
			temp = AdditionWithAggressiveInlining(_2, _2);
			temp = AdditionWithAggressiveInlining(_3, _3);
			temp = AdditionWithAggressiveInlining(_4, _4);
			temp = AdditionWithAggressiveInlining(_5, _5);
		}

		[Benchmark]
		public void IntegerAddStruct()
		{
			temp = Do<int, g__Addition_1>(_1, _1);
			temp = Do<int, g__Addition_1>(_2, _2);
			temp = Do<int, g__Addition_1>(_3, _3);
			temp = Do<int, g__Addition_1>(_4, _4);
			temp = Do<int, g__Addition_1>(_5, _5);
		}

		[Benchmark]
		public void IntegerAddLinq()
		{
			temp = Addition(_1, _1);
			temp = Addition(_2, _2);
			temp = Addition(_3, _3);
			temp = Addition(_4, _4);
			temp = Addition(_5, _5);
		}

		public struct g__AdditionWithAggressiveInlining_1 : IFunction<int, int, int>
		{
			[MethodImpl(MethodImplOptions.AggressiveInlining)]
			public int Do(int a, int b) => a + b;
		}

		public struct g__Addition_1 : IFunction<int, int, int>
		{
			public int Do(int a, int b) => a + b;
		}

		[MethodImpl(MethodImplOptions.AggressiveInlining)]
		public static T DoWithAggressiveInlining<T, Addition>(T a, T b)
			where Addition : struct, IFunction<T, T, T>
		{
			Addition addition = default;
			return addition.Do(a, b);
		}

		public static T Do<T, Addition>(T a, T b)
			where Addition : struct, IFunction<T, T, T>
		{
			Addition addition = default;
			return addition.Do(a, b);
		}

		[MethodImpl(MethodImplOptions.AggressiveInlining)]
		public static T AdditionWithAggressiveInlining<T>(T a, T b)
		{
			return AdditionImplementation<T>.Function(a, b);
		}

		public static T Addition<T>(T a, T b)
		{
			return AdditionImplementation<T>.Function(a, b);
		}

		internal static class AdditionImplementation<T>
		{
			internal static Func<T, T, T> Function = (T a, T b) =>
			{
				ParameterExpression A = Expression.Parameter(typeof(T));
				ParameterExpression B = Expression.Parameter(typeof(T));
				Expression BODY = Expression.Add(A, B);
				Function = Expression.Lambda<Func<T, T, T>>(BODY, A, B).Compile();
				return Function(a, b);
			};
		}
	}

	public interface IFunction<A, B, C> { C Do(A a, B b); }

	public class Program
	{
		public static void Main(string[] args)
		{
			var summary = BenchmarkRunner.Run<Benchmarks>();
		}
	}
}

Benchmark 1 Results [click to expand]

BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362
Intel Core i7-4790K CPU 4.00GHz (Haswell), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.0.100
  [Host]     : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
  DefaultJob : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT

Method	Mean	Error	StdDev
IntegerAdd	0.6769 ns	0.0183 ns	0.0171 ns
IntegerAddStructWithAggressiveInlining	0.9609 ns	0.0453 ns	0.0424 ns
IntegerAddLinqWithAggressiveInlining	10.3589 ns	0.1538 ns	0.1438 ns
IntegerAddStruct	6.5660 ns	0.1569 ns	0.1468 ns
IntegerAddLinq	10.9472 ns	0.1388 ns	0.1298 ns

Benchmark 2 Code [click to expand]

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

namespace Benchmarks
{
	public class Benchmarks
	{
		private static int[] data;
		private static int sum;

		[GlobalSetup]
		public void Setup()
		{
			const int N = 10;
			int[] dataArray = new int[N];
			for (int i = 0; i < N; i++)
			{
				dataArray[i] = i;
			}
			data = dataArray;
		}

		[Benchmark]
		public void Control()
		{
			sum = 0;
			foreach (int i in data)
			{
				if (i % 2 == 0)
				{
					sum += i;
				}
			}
		}

		[Benchmark]
		public void LinqWhereLambda()
		{
			sum = 0;
			foreach (int i in data.Where(i => i % 2 == 0))
			{
				sum += i;
			}
		}

		[Benchmark]
		public void LinqWhere()
		{
			sum = 0;
			foreach (int i in data.Where(IsEven))
			{
				sum += i;
			}
		}

		[Benchmark]
		public void CustomWhereLambda()
		{
			sum = 0;
			foreach (int i in data.CustomWhere(i => i % 2 == 0))
			{
				sum += i;
			}
		}

		[Benchmark]
		public void CustomWhere()
		{
			sum = 0;
			foreach (int i in data.CustomWhere(IsEven))
			{
				sum += i;
			}
		}

		[Benchmark]
		public void GenericStructWhere()
		{
			sum = 0;
			foreach (int i in data.Where<int, g__IsEven_1>())
			{
				sum += i;
			}
		}

		[Benchmark]
		public void GenericStructWhereAction()
		{
			sum = 0;
			data.Where<int, g__IsEven_1, g__Action_1>();
		}

		[Benchmark]
		public void CustomWhereWithAggressiveInlining()
		{
			sum = 0;
			foreach (int i in data.CustomWhere(IsEvenWithAggressiveInlining))
			{
				sum += i;
			}
		}

		[Benchmark]
		public void GenericStructWhereWithAggressiveInlining()
		{
			sum = 0;
			foreach (int i in data.Where<int, g__IsEvenWithAggressiveInlining_1>())
			{
				sum += i;
			}
		}

		[Benchmark]
		public void GenericStructWhereActionWithAggressiveInlining()
		{
			sum = 0;
			data.Where<int, g__IsEvenWithAggressiveInlining_1, g__ActionWithAggressiveInlining_1>();
		}

		public struct g__ActionWithAggressiveInlining_1 : IAction<int>
		{
			[MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
			public void Do(int a) => sum += a;
		}

		public struct g__IsEvenWithAggressiveInlining_1 : IFunction<int, bool>
		{
			[MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
			public bool Do(int a) => IsEvenWithAggressiveInlining(a);
		}

		public struct g__Action_1 : IAction<int>
		{
			public void Do(int a) => sum += a;
		}

		public struct g__IsEven_1 : IFunction<int, bool>
		{
			public bool Do(int a) => IsEven(a);
		}

		[MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
		public static bool IsEvenWithAggressiveInlining(int i) => i % 2 == 0;

		public static bool IsEven(int i) => i % 2 == 0;

	}

	#region Interface Types That Would Be Added To .NET

	public interface IAction<A> { void Do(A a); }
	public interface IFunction<A, B> { B Do(A a); }

	#endregion

	public static class Extensions
	{
		public static IEnumerable<T> CustomWhere<T>(this T[] ienumerable, Predicate<T> where)
		{
			foreach (T value in ienumerable)
			{
				if (where(value))
				{
					yield return value;
				}
			}
		}

		public static IEnumerable<T> Where<T, Predicate>(this T[] ienumerable)
			/// There should be syntax sugar on the constraints to
			/// make them look more like function constraints.
			where Predicate : struct, IFunction<T, bool> // -> where Predicate : [bool method(T)]
		{
			#region Code that should be unnecessary

			Predicate predicate = default;

			#endregion

			/// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

			foreach (T value in ienumerable)
			{
				if (predicate.Do(value))
				{
					yield return value;
				}
			}
		}

		public static void Where<T, Predicate, Action>(this T[] ienumerable)
			/// There should be syntax sugar on the constraints to
			/// make them look more like function constraints.
			where Predicate : struct, IFunction<T, bool> // -> where Predicate : [bool method(T)]
			where Action : struct, IAction<T>            // -> where Action    : [void method(T)]
		{
			#region Code that should be unnecessary

			Predicate predicate = default;
			Action action = default;

			#endregion

			/// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

			foreach (T value in ienumerable)
			{
				if (predicate.Do(value))
				{
					action.Do(value);
				}
			}
		}
	}

	public class Program
	{
		public static void Main(string[] args)
		{
			var summary = BenchmarkRunner.Run<Benchmarks>();
		}
	}
}

Benchmark 2 Results [click to expand]

BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362
Intel Core i7-4790K CPU 4.00GHz (Haswell), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.0.100
  [Host]     : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
  DefaultJob : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT

Method	Mean	Error	StdDev
Control	10.001 ns	0.1150 ns	0.1076 ns
LinqWhereLambda	71.749 ns	1.2415 ns	1.1613 ns
LinqWhere	82.121 ns	1.4050 ns	1.2455 ns
CustomWhereLambda	81.201 ns	1.2469 ns	1.0412 ns
CustomWhere	91.495 ns	1.7966 ns	2.0690 ns
GenericStructWhere	58.712 ns	0.5980 ns	0.5301 ns
GenericStructWhereAction	8.247 ns	0.0395 ns	0.0350 ns
CustomWhereWithAggressiveInlining	88.845 ns	1.1319 ns	1.0588 ns
GenericStructWhereWithAggressiveInlining	57.707 ns	0.2212 ns	0.2069 ns
GenericStructWhereActionWithAggressiveInlining	8.206 ns	0.0193 ns	0.0180 ns

Examples

Here are code exampes of this feature. These code examples all compile in current C# 8.0, but it results in ugly code. I have added comments to demonstrate what the syntax could look like if this feature was added.

Code Examples [click to expand]

using System;
using System.Collections.Generic;
using IntArrayEnumerator = System.ValueTuple<int, int[]>;

namespace Example
{
    public class Program
    {
        public static void Main()
        {
            // These are examples of "compile time delegates". Currently
            // you have to wrap methods inside of a struct that implements an
            // interface. Theoretically the C# language could be modified to allow
            // you to pass in functions via generic arguments so that you do not
            // have to wrap methods inside a custom struct.

            // Why? Delegates have the overhead of being invoked at runtime. They
            // are not inlined/resolved at compile time. Using struct-wrapped-functions
            // as generic parameters means the function is resolved/in-lined by the
            // end of the JIT.

            Console.WriteLine("IterationExample...");
            IterationExample.Run();

            Console.WriteLine("SumAndProductExample...");
            SumAndProductExample.Run();

            Console.WriteLine("FactorialExample...");
            FactorialExample.Run();

            Console.WriteLine("BinomeialCoefficientExample...");
            BinomeialCoefficientExample.Run();

            Console.WriteLine("IEnumerableExample...");
            IEnumerableExample.Run();

            Console.WriteLine("GraphSearchExample...");
            GraphSearchExample.Run();
        }
    }

    #region Interface Types That Would Be Added To .NET

    // These types would be new types in the .NET libraries

    public interface IAction { void Do(); }
    public interface IAction<A> { void Do(A a); }
    public interface IAction<A, B> { void Do(A a, B b); }
    public interface IFunction<A> { A Do(); }
    public interface IFunction<A, B> { B Do(A a); }
    public interface IFunction<A, B, C> { C Do(A a, B b); }
    public interface IAction1Ref<A> { void Do(ref A a); }
    public interface IAction1Out<A> { void Do(out A a); }
    public interface IAction2Out<A, B> { void Do(out A a, out B b); }
    public interface IAction1In1Out<A, B> { void Do(A a, out B b); }
    public interface IAction1In2Out<A, B, C> { void Do(A a, out B b, out C c); }
    public interface IFunction1Out<A, B> { B Do(out A a); }
    public interface IFunction2Out<A, B, C> { C Do(out A a, out B b); }
    public interface IFunction1Ref<A, B> { B Do(ref A a); }
    public interface IFunction1In1Ref<A, B, C> { C Do(A a, ref B b); }

    // there would need to be more... I just stopped here

    #endregion

    #region IterationExample

    public static class IterationExample
    {
        public static void Run()
        {
            int[] a = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, };

            /// Instead of passing in g__ConsoleWrite_1 you should be able to
            /// pass in ConsoleWrite as the generic argument and g__ConsoleWrite_1
            /// would be generated at compile time.

            a.ForEach<int, g__ConsoleWrite_1>(); // -> a.ForEach<int, ConsoleWrite>();
            Console.WriteLine();

            a.ForEach<int, g__ConsoleWrite_1, g__IsEven_1>(); // -> a.ForEach<int, ConsoleWrite, IsEven>();
            Console.WriteLine();

            /// The language could also allow for static, compile-time
            /// expressions to be used as generic arguments. Then you could
            /// write something similar to the following. Capture variables
            /// would not be supported as it would need to generate a method
            /// at compile time. This would compile to a seperate static
            /// method (NOT a delegate) that would be wrapped with a compiler
            /// generated struct, and the struct would be used as the generic
            /// parameter.

            //a.ForEach<int, { i => Console.Write(i) }> ();
            //Console.WriteLine();
            //a.ForEach<int, { i => Console.Write(i) }, { i => i % 2 == 0 }>();
            //Console.WriteLine();
        }

        #region Types that could be generated at compile time

        public struct g__ConsoleWrite_1 : IAction<int>
        {
            public void Do(int i) => ConsoleWrite(i);
        }

        public struct g__IsEven_1 : IFunction<int, bool>
        {
            public bool Do(int i) => IsEven(i);
        }

        #endregion

        public static void ConsoleWrite(int i) => Console.Write(i);
        public static bool IsEven(int i) => i % 2 == 0;

        public static void ForEach<T, Action>(this T[] array)
            /// There should be syntax sugar on the constraints to
            /// make them look more like function constraints.
            where Action : struct, IAction<T> // -> where [void Action(T)]
        {
            #region Code that should be unnecessary

            Action action = default;

            #endregion

            /// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

            for (int i = 0; i < array.Length; i++) // -> for (int i = 0; i < array.Length; i++)
            {                                      // -> {
                action.Do(array[i]);               // ->     Action(array[i]);
            }                                      // -> }
        }

        public static void ForEach<T, Action, Where>(this T[] array)
            /// There should be syntax sugar on the constraints to
            /// make them look more like function constraints.
            where Action : struct, IAction<T>        // -> where Action : [void method(T)]
            where Where : struct, IFunction<T, bool> // -> where Where  : [bool method(T)]
        {
            #region Code that should be unnecessary

            Action action = default;
            Where where = default;

            #endregion

            /// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

            for (int i = 0; i < array.Length; i++) // -> for (int i = 0; i < array.Length; i++)
            {                                      // -> {
                if (where.Do(array[i]))            // ->     if (Where(array[i]))
                {                                  // ->     {
                    action.Do(array[i]);           // ->         Action(array[i]);
                }                                  // ->     }
            }                                      // -> }
        }
    }

    #endregion

    #region SumAndProductExample

    public static class SumAndProductExample
    {
        public static void Run()
        {
            int[] a = new int[] { 7, 7, 8, 8, 9, 9, 10, };
            float[] b = new float[] { 7, 7, 8, 8, 9, 9, 10, };

            /// Instead of passing in g__Addition_1 you should be able to
            /// pass in Addition as the generic argument and g__Addition_1
            /// would be generated at compile time.

            Console.WriteLine(Compute<int, g__Addition_1>(a));         // -> Console.WriteLine(Compute<int, Addition>(a));
            Console.WriteLine(Compute<float, g__Addition_2>(b));       // -> Console.WriteLine(Compute<float, Addition>(a));
            Console.WriteLine(Compute<int, g__Multiplication_1>(a));   // -> Console.WriteLine(Compute<int, Multiplication>(b));
            Console.WriteLine(Compute<float, g__Multiplication_2>(b)); // -> Console.WriteLine(Compute<float, Multiplication>(b));

            /// The language could also allow for static, compile-time
            /// expressions to be used as generic arguments. Then you could
            /// write something similar to the following. Capture variables
            /// would not be supported as it would need to generate a method
            /// at compile time. This would compile to a seperate static
            /// method (NOT a delegate) that would be wrapped with a compiler
            /// generated struct, and the struct would be used as the generic
            /// parameter.

            //Console.WriteLine(Compute<int,   { (a, b) => a + b }>(a));
            //Console.WriteLine(Compute<float, { (a, b) => a + b }>(b));
            //Console.WriteLine(Compute<int,   { (a, b) => a * b }>(a));
            //Console.WriteLine(Compute<float, { (a, b) => a * b }>(b));
        }

        #region Types that could be generated at compile time

        public struct g__Addition_1 : IFunction<int, int, int>
        {
            public int Do(int a, int b) => Addition(a, b);
        }

        public struct g__Addition_2 : IFunction<float, float, float>
        {
            public float Do(float a, float b) => Addition(a, b);
        }

        public struct g__Multiplication_1 : IFunction<int, int, int>
        {
            public int Do(int a, int b) => Multiplication(a, b);
        }

        public struct g__Multiplication_2 : IFunction<float, float, float>
        {
            public float Do(float a, float b) => Multiplication(a, b);
        }

        #endregion

        // These functions should be able to be static local fuctions. Then
        // all the functionality could be inside the Main method rather
        // than seperated into seperate methods.
        public static int Addition(int a, int b) => a + b;
        public static float Addition(float a, float b) => a + b;
        public static int Multiplication(int a, int b) => a * b;
        public static float Multiplication(float a, float b) => a * b;

        public static T Compute<T, Binary>(params T[] array)
            /// There should be syntax sugar on the constraints to
            /// make them look more like function constraints.
            where Binary : struct, IFunction<T, T, T> // -> where Binary : [T method(T, T)]
        {
            #region Code that should be unnecessary

            Binary binary = default;

            #endregion

            /// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

            T result = array[0];                      // -> T result = array[0];
            for (int i = 1; i < array.Length; i++)    // -> for (int i = 1; i < array.Length; i++)
            {                                         // -> {
                result = binary.Do(result, array[i]); // ->     result = Binary(result, array[i]);
            }                                         // -> }
            return result;                            // -> return result;
        }
    }

    #endregion

    #region FactorialExample

    public static class FactorialExample
    {
        public static void Run()
        {
            /// Instead of passing in g__Decrement_1 you should be able to
            /// pass in Decrement as the generic argument and g__Decrement_1
            /// would be generated at compile time.

            int factorialInt7 =      // -> int factorialInt7 =
                Factorial<           // ->     Factorial<
                    int,             // ->         int,
                    g__Decrement_1,  // ->         Decrement,
                    g__IsInteger_1,  // ->         IsInteger,
                    g__IsPositive_1, // ->         IsPositive,
                    g__Multiply_1    // ->         Multiply
                    >(7);            // ->         >(7);

            Console.WriteLine(factorialInt7);

            float factorialFloat7 =  // -> float factorialFloat7 =
                Factorial<           // ->     Factorial<
                    float,           // ->         float,
                    g__Decrement_2,  // ->         Decrement,
                    g__IsInteger_2,  // ->         IsInteger,
                    g__IsPositive_2, // ->         IsPositive,
                    g__Multiply_2    // ->         Multiply
                    >(7f);           // ->         >(7f);

            Console.WriteLine(factorialFloat7);

            /// The language could also allow for static, compile-time
            /// expressions to be used as generic arguments. Then you could
            /// write something similar to the following. Capture variables
            /// would not be supported as it would need to generate a method
            /// at compile time. This would compile to a seperate static
            /// method (NOT a delegate) that would be wrapped with a compiler
            /// generated struct, and the struct would be used as the generic
            /// parameter.

            //float factorialInt7 =
            //    Factorial <
            //        int,
            //        { (ref a) => --a },
            //        { a => true },
            //        { a => a > 0 },
            //        { (a, b) => a * b }
            //        > (7f);
            //
            //Console.WriteLine(factorialInt7);
            //
            //float factorialFloat7 =
            //    Factorial<
            //        float,
            //        { (ref a) => --a },
            //        { a => true },
            //        { a => a > 0 },
            //        { (a, b) => a * b }
            //        >(7f);
            //
            //Console.WriteLine(factorialFloat7);
        }

        #region Types that should be generated at compile time

        public struct g__Multiply_1 : IFunction<int, int, int>
        {
            public int Do(int a, int b) => Multiply(a, b);
        }

        public struct g__Multiply_2 : IFunction<float, float, float>
        {
            public float Do(float a, float b) => Multiply(a, b);
        }

        public struct g__Decrement_1 : IAction1Ref<int>
        {
            public void Do(ref int a) => Decrement(ref a);
        }

        public struct g__Decrement_2 : IAction1Ref<float>
        {
            public void Do(ref float a) => Decrement(ref a);
        }

        public struct g__IsInteger_1 : IFunction<int, bool>
        {
            public bool Do(int a) => IsInteger(a);
        }

        public struct g__IsInteger_2 : IFunction<float, bool>
        {
            public bool Do(float a) => IsInteger(a);
        }

        public struct g__IsPositive_1 : IFunction<int, bool>
        {
            public bool Do(int a) => IsPositive(a);
        }

        public struct g__IsPositive_2 : IFunction<float, bool>
        {
            public bool Do(float a) => IsPositive(a);
        }

        #endregion

        // These functions should be able to be static local fuctions. Then
        // all the functionality could be inside the Example method rather
        // than seperated into seperate methods.
        public static int Multiply(int a, int b) => a * b;
        public static float Multiply(float a, float b) => a * b;
        public static void Decrement(ref int a) => a--;
        public static void Decrement(ref float a) => a--;
        public static bool IsInteger(int a) => true;
        public static bool IsInteger(float a) => a % 1 == 0;
        public static bool IsPositive(int a) => a > 0;
        public static bool IsPositive(float a) => a > 0;

        public static T Factorial<T, Decrement, IsInteger, IsPositive, Multiplication>(T a)
            /// There should be syntax sugar on the constraints to
            /// make them look more like function constraints.
            where Decrement : struct, IAction1Ref<T>            // -> where Decrement  : [void method(ref T)]
            where IsInteger : struct, IFunction<T, bool>        // -> where IsInteger  : [bool method(T)]
            where IsPositive : struct, IFunction<T, bool>       // -> where IsPositive : [bool method(T)]
            where Multiplication : struct, IFunction<T, T, T>   // -> where Multiply   : [T method(T, T)]
        {
            #region Code that should be unnecessary

            Decrement decrement = default;
            IsInteger isInteger = default;
            IsPositive isPositive = default;
            Multiplication multiplication = default;

            #endregion

            /// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

            if (!isInteger.Do(a) || !isPositive.Do(a))           // -> if (!IsInteger(a) || !IsPositive(a))
            {                                                    // -> {
                throw new ArgumentOutOfRangeException(nameof(a), // ->     throw new ArgumentOutOfRangeException(nameof(a),
                    "Parameter is not a positive integer.");     // ->         "Parameter is not a positive integer.");
            }                                                    // -> }
            T current = a;                                       // -> T current = a;
            T result = a;                                        // -> T result = a;
            decrement.Do(ref current);                           // -> decrement(ref current);
            while (isPositive.Do(current))                       // -> while (IsPositive(current))
            {                                                    // -> {
                result = multiplication.Do(result, current);     // ->     result = Multiplication(result, current);
                decrement.Do(ref current);                       // ->     Decrement(ref current);
            }                                                    // -> }
            return result;                                       // -> return result;
        }
    }

    #endregion

    #region Binomial Coefficient

    public static class BinomeialCoefficientExample
    {
        public static void Run()
        {
            /// Instead of passing in g__Decrement_1 you should be able to
            /// pass in Decrement as the generic argument and g__Decrement_1
            /// would be generated at compile time.

            int binomialCoefficientInt_7_5 = // -> int binomialCoefficientInt_7_5 =
                BinomialCoefficient<         // ->     BinomialCoefficient<
                    int,                     // ->         int,
                    g__Factorial_1,          // ->         Factorial<int, Decrement, IsInteger, IsPositive, Multiplication>,
                    g__Division_1,           // ->         Division,
                    g__Multiplication_1,     // ->         Multiplication,
                    g__Subtraction_1         // ->         Subtraction
                    >(7, 5);                 // ->         >(7, 5);

            Console.WriteLine(binomialCoefficientInt_7_5);
        }

        #region Types that should be generated at compile time

        public struct g__Factorial_1 : IFunction<int, int>
        {
            public int Do(int a) => Factorial<int, g__Decrement_1, g__IsInteger_1, g__IsPositive_1, g__Multiplication_1>(a);
        }

        public struct g__Subtraction_1 : IFunction<int, int, int>
        {
            public int Do(int a, int b) => Subtraction(a, b);
        }

        public struct g__Subtraction_2 : IFunction<float, float, float>
        {
            public float Do(float a, float b) => Subtraction(a, b);
        }

        public struct g__Multiplication_1 : IFunction<int, int, int>
        {
            public int Do(int a, int b) => Multiply(a, b);
        }

        public struct g__Multiplication_2 : IFunction<float, float, float>
        {
            public float Do(float a, float b) => Multiply(a, b);
        }

        public struct g__Division_1 : IFunction<int, int, int>
        {
            public int Do(int a, int b) => Division(a, b);
        }

        public struct g__Division_2 : IFunction<float, float, float>
        {
            public float Do(float a, float b) => Division(a, b);
        }

        public struct g__Decrement_1 : IAction1Ref<int>
        {
            public void Do(ref int a) => Decrement(ref a);
        }

        public struct g__Decrement_2 : IAction1Ref<float>
        {
            public void Do(ref float a) => Decrement(ref a);
        }

        public struct g__IsInteger_1 : IFunction<int, bool>
        {
            public bool Do(int a) => IsInteger(a);
        }

        public struct g__IsInteger_2 : IFunction<float, bool>
        {
            public bool Do(float a) => IsInteger(a);
        }

        public struct g__IsPositive_1 : IFunction<int, bool>
        {
            public bool Do(int a) => IsPositive(a);
        }

        public struct g__IsPositive_2 : IFunction<float, bool>
        {
            public bool Do(float a) => IsPositive(a);
        }

        #endregion

        // These functions should be able to be static local fuctions. Then
        // all the functionality could be inside the Example method rather
        // than seperated into seperate methods.
        public static int Subtraction(int a, int b) => a - b;
        public static float Subtraction(float a, float b) => a - b;
        public static int Multiply(int a, int b) => a * b;
        public static float Multiply(float a, float b) => a * b;
        public static int Division(int a, int b) => a / b;
        public static float Division(float a, float b) => a / b;
        public static void Decrement(ref int a) => a--;
        public static void Decrement(ref float a) => a--;
        public static bool IsInteger(int a) => true;
        public static bool IsInteger(float a) => a % 1 == 0;
        public static bool IsPositive(int a) => a > 0;
        public static bool IsPositive(float a) => a > 0;

        public static T Factorial<T, Decrement, IsInteger, IsPositive, Multiply>(T a)
            /// There should be syntax sugar on the constraints to
            /// make them look more like function constraints.
            where Decrement : struct, IAction1Ref<T>      // -> where Decrement  : [void method(ref T)]
            where IsInteger : struct, IFunction<T, bool>  // -> where IsInteger  : [bool method(T)]
            where IsPositive : struct, IFunction<T, bool> // -> where IsPositive : [bool method(T)]
            where Multiply : struct, IFunction<T, T, T>   // -> where Multiply   : [T method(T, T)]
        {
            #region Code that should be unnecessary

            Decrement decrement = default;
            IsInteger isInteger = default;
            IsPositive isPositive = default;
            Multiply multiply = default;

            #endregion

            /// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

            if (!isInteger.Do(a) || !isPositive.Do(a))           // -> if (!IsInteger(a) || !IsPositive(a))
            {                                                    // -> {
                throw new ArgumentOutOfRangeException(nameof(a), // ->     throw new ArgumentOutOfRangeException(nameof(a),
                    "Parameter is not a positive integer.");     // ->         "Parameter is not a positive integer.");
            }                                                    // -> }
            T current = a;                                       // -> T current = a;
            T result = a;                                        // -> T result = a;
            decrement.Do(ref current);                           // -> decrement(ref current);
            while (isPositive.Do(current))                       // -> while (IsPositive(current))
            {                                                    // -> {
                result = multiply.Do(result, current);           // ->     result = Multiply(result, current);
                decrement.Do(ref current);                       // ->     Decrement(ref current);
            }                                                    // -> }
            return result;                                       // -> return result;
        }

        public static T BinomialCoefficient<T, Factorial, Division, Multiplication, Subtraction>(T n, T k)
            /// There should be syntax sugar on the constraints to
            /// make them look more like function constraints.
            where Factorial : struct, IFunction<T, T>         // -> where Factorial      : [T method(T)]
            where Division : struct, IFunction<T, T, T>       // -> where Division       : [T method(T, T)]
            where Multiplication : struct, IFunction<T, T, T> // -> where Multiplication : [T method(T, T)]
            where Subtraction : struct, IFunction<T, T, T>    // -> where Subtraction    : [T method(T, T)]
        {
            #region Code that should be unnecessary

            Factorial factorial = default;
            Division division = default;
            Multiplication multiplication = default;
            Subtraction subtraction = default;

            #endregion

            /// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

            return division.Do(                           // -> return Division(
                factorial.Do(n),                          // ->     Factorial(n),
                multiplication.Do(                        // ->     Multiplication(
                    factorial.Do(k),                      // ->         Factorial(k),
                    factorial.Do(subtraction.Do(n, k)))); // ->         Factorial(Subtraction(n, k))));
        }
    }

    #endregion

    #region IEnumerableExample

    public static class IEnumerableExample
    {
        // I don't consider replicating IEnumerable with functions as very pratical,
        // but I included this example simply to show it is possible.

        #region Types that could be generated at compile time

        public struct g__GetEnumerator_1 : IFunction<int[], IntArrayEnumerator>
        {
            public IntArrayEnumerator Do(int[] a) => GetEnumerator(a);
        }

        public struct g__GetCurrent_1 : IFunction<IntArrayEnumerator, int>
        {
            public int Do(IntArrayEnumerator a) => GetCurrent(a);
        }

        public struct g__MoveNext_1 : IFunction1Ref<IntArrayEnumerator, bool>
        {
            public bool Do(ref IntArrayEnumerator a) => MoveNext(ref a);
        }

        public struct g__ConsoleWrite_1 : IAction<int>
        {
            public void Do(int a) => ConsoleWrite(a);
        }

        #endregion

        public static void Run()
        {
            int[] a = new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, };

            /// Instead of passing in g__GetEnumerator_1 you should be able to
            /// pass in GetEnumerator as the generic argument and g__GetEnumerator_1
            /// would be generated at compile time.

            Iterate<
                int[],
                int,
                IntArrayEnumerator,
                g__GetEnumerator_1,   // -> GetEnumerator
                g__GetCurrent_1,      // -> GetCurrent
                g__MoveNext_1,        // -> MoveNext
                g__ConsoleWrite_1     // -> ConsoleWrite
                >(a);

            /// The language could also allow for static, compile-time
            /// expressions to be used as generic arguments. Then you could
            /// write something similar to the following. Capture variables
            /// would not be supported as it would need to generate a method
            /// at compile time. This would compile to a seperate static
            /// method (NOT a delegate) that would be wrapped with a compiler
            /// generated struct, and the struct would be used as the generic
            /// parameter.

            //Iterate<
            //    int[],
            //    int,
            //    IntArrayEnumerator,
            //    { a => (0, a) },
            //    { a => a.Item2[a.Item1] },
            //    { (ref a) => (a.Item1 < a.Item2.Length - 1 ? a.Item1 += 1 : 0) != 0 },
            //    { i => Console.WriteLine(i) }
            //    >(a);

            Console.WriteLine();
        }

        // These functions should be able to be static local fuctions. Then
        // all the functionality could be inside the Main method rather
        // than seperated into seperate methods.
        public static IntArrayEnumerator GetEnumerator(int[] a) => (0, a);
        public static int GetCurrent(IntArrayEnumerator a) => a.Item2[a.Item1];
        public static bool MoveNext(ref IntArrayEnumerator a) => (a.Item1 < a.Item2.Length - 1 ? a.Item1 += 1 : 0) != 0;
        public static void ConsoleWrite(int i) => Console.Write(i);

        public static void Iterate<A, B, Enumerator, GetEnumerator, GetCurrent, MoveNext, Action>(A a)
            /// There should be syntax sugar on the constraints to
            /// make them look more like function constraints.
            where GetEnumerator : struct, IFunction<A, Enumerator>   // -> where GetEnumerator : [Enumerator (A)]
            where GetCurrent : struct, IFunction<Enumerator, B>      // -> where GetCurrent    : [B (Enumerator)]
            where MoveNext : struct, IFunction1Ref<Enumerator, bool> // -> where MoveNext      : [bool (ref Enumerator)]
            where Action : struct, IAction<B>                        // -> where Action        : [void (B)]
        {
            #region Code that should be unnecessary

            GetEnumerator getEnumerator = default;
            GetCurrent getCurrent = default;
            MoveNext moveNext = default;
            Action action = default;

            #endregion

            /// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

            Enumerator enumerator = getEnumerator.Do(a); // -> Enumerator enumerator = GetEnumerator(a);
            do                                           // -> do
            {                                            // -> {
                B current = getCurrent.Do(enumerator);   // ->     B current = GetCurrent(enumerator);
                action.Do(current);                      // ->     Action(current);
            } while (moveNext.Do(ref enumerator));       // -> } while (MoveNext(ref enumerator));
        }
    }

    #endregion

    #region GraphSearchExample

    public static class GraphSearchExample
    {
        public static void Run()
        {
            Console.Write("Path:");
            GraphSearch<
                int,
                int,
                g__Zero_1,
                g__Addition_1,
                g__Compare_1,
                g__Neighors_1,
                g__Heuristic_1,
                g__Cost_1,
                g__Check_1,
                g__ConsoleWrite_1
                >(0, out int totalCost);
            Console.WriteLine();
            Console.Write("Total Cost: " + totalCost);
            Console.WriteLine();
        }

        #region Types that could be generated at compile time

        public struct g__Zero_1 : IFunction<int>
        {
            public int Do() => Zero();
        }

        public struct g__Addition_1 : IFunction<int, int, int>
        {
            public int Do(int a, int b) => Addition(a, b);
        }

        public struct g__Compare_1 : IFunction<int, int, CompareResult>
        {
            public CompareResult Do(int a, int b) => Compare(a, b);
        }

        public struct g__Neighors_1 : IFunction<int, IEnumerable<int>>
        {
            public IEnumerable<int> Do(int a) => Neighbors(a);
        }

        public struct g__Heuristic_1 : IFunction<int, int>
        {
            public int Do(int a) => Heuristic(a);
        }

        public struct g__Cost_1 : IFunction<int, int, int>
        {
            public int Do(int a, int b) => Cost(a, b);
        }

        public struct g__Check_1 : IFunction<int, GraphSearchStatus>
        {
            public GraphSearchStatus Do(int a) => Check(a);
        }

        public struct g__ConsoleWrite_1 : IAction<int>
        {
            public void Do(int i) => ConsoleWrite(i);
        }

        #endregion

        public static int Zero() => 0;

        public static int Addition(int a, int b) => a + b;

        public static CompareResult Compare(int a, int b) =>
            a < b ? CompareResult.Less :
            a > b ? CompareResult.Greater :
            CompareResult.Equal;

        // visualization
        //
        //    [0]-----(1)---->[1]
        //     |               |
        //     |               |
        //    (99)            (2)
        //     |               |
        //     |               |
        //     v               v
        //    [3]<----(5)-----[2]
        //
        //    [nodes in brackets]
        //    (edge costs in parenthases)

        public static IEnumerable<int> Neighbors(int node) => node switch
        {
            0 => new int[] { 1, 3 },
            1 => new int[] { 2 },
            2 => new int[] { 3 },
            _ => throw new Exception(),
        };

        public static int Heuristic(int node) => node switch
        {
            0 => 2,
            1 => 4,
            2 => 2,
            3 => 0,
            _ => throw new Exception(),
        };

        public static int Cost(int a, int b) => (a, b) switch
        {
            (0, 1) => 1,
            (0, 3) => 99,
            (1, 2) => 2,
            (2, 3) => 5,
            _ => throw new Exception(),
        };

        public static GraphSearchStatus Check(int node) =>
            // Note: I did not add a condition to "Break"
            // the algorithm here, but that is possible too.
            node == 3 ? GraphSearchStatus.Goal :
            GraphSearchStatus.Continue;

        public static void ConsoleWrite(int i) => Console.Write(" " + i);

        public static void GraphSearch<Node, Value, Zero, Addition, Compare, Neighbors, Heuristic, Cost, Check, Action>(Node start, out Value totalCost)
            /// There should be syntax sugar on the constraints to
            /// make them look more like function constraints.
            where Zero : struct, IFunction<Value>                          // -> where Zero      : [Value method()]
            where Addition : struct, IFunction<Value, Value, Value>        // -> where Addition  : [Value method(Value, Value)]
            where Compare : struct, IFunction<Value, Value, CompareResult> // -> where Compare   : [CompareResult method(Value, Value)]
            where Neighbors : struct, IFunction<Node, IEnumerable<Node>>   // -> where Neighbors : [IEnumerable<Node> method(Node)]
            where Heuristic : struct, IFunction<Node, Value>               // -> where Heuristic : [Value method(Node))]
            where Cost : struct, IFunction<Node, Node, Value>              // -> where Cost      : [Value method(Node, Node))]
            where Check : struct, IFunction<Node, GraphSearchStatus>       // -> where Check     : [GraphSearchStatus method(Node)]
            where Action : struct, IAction<Node>                           // -> where Action    : [void method(Node)]
        {
            // This graph search implementation uses the A* algorithm.

            #region Code that should be unnecessary

            Zero zero = default;
            Addition addition = default;
            Compare compare = default;
            Neighbors neighbors = default;
            Heuristic heuristic = default;
            Cost cost = default;
            Check check = default;
            Action action = default;

            #endregion

            /// The generic parameter should be invocable directly the ".Do" calls should be unnecessary.

            Node<Node, Value> head = new Node<Node, Value>()
            {
                This = start,
                Previous = null,
                Priority = zero.Do(), // -> Priority = Zero(),
                Cost = zero.Do(), // -> Cost = Zero(),
            };

            void Enqueue(Node<Node, Value> node)
            {
                if (head is null)
                {
                    head = node;
                }
                else if (compare.Do(head.Priority, node.Priority) == CompareResult.Greater)
                {
                    node.Next = head;
                    head = node;
                }
                else
                {
                    Node<Node, Value> value = head;
                    while (value.Next != null ||
                        compare.Do(value.Priority, node.Priority) == CompareResult.Greater)
                    {
                        value = value.Next;
                    }
                    node.Next = value.Next;
                    value.Next = node;
                }
            }

            Node<Node, Value> Dequeue()
            {
                Node<Node, Value> value = head;
                head = head.Next;
                return value;
            }

            static Node<Node, Value> BuildPath(Node<Node, Value> node)
            {
                Node<Node, Value> previous = null;
                while (!(node is null))
                {
                    node.Next = previous;
                    previous = node;
                    node = node.Previous;
                }
                return previous;
            }

            while (!(head is null))
            {
                Node<Node, Value> current = Dequeue();
                GraphSearchStatus status = check.Do(current.This); // -> GraphSearchStatus status = Check(current.This);
                if (status == GraphSearchStatus.Break)
                {
                    break;
                }
                else if (status == GraphSearchStatus.Goal)
                {
                    totalCost = current.Cost;
                    Node<Node, Value> node = BuildPath(current);
                    while (!(node is null))
                    {
                        action.Do(node.This); // -> Action(node.This);
                        node = node.Next;
                    }
                    return;
                }
                else
                {
                    foreach (Node neighbor in neighbors.Do(current.This)) // -> foreach (Node neighbor in Neighbors(current.This))
                    {
                        Value costValue = addition.Do(current.Cost, cost.Do(current.This, neighbor)); // -> Value costValue = Addition(current.Cost, Cost(current.This, neighbor));
                        Enqueue(new Node<Node, Value>()
                        {
                            Previous = current,
                            This = neighbor,
                            Priority = addition.Do(heuristic.Do(neighbor), costValue), // -> Priority = Addition(Heuristic(neighbor), costValue),
                            Cost = costValue,
                        });
                    }
                }
            }
            totalCost = default;
        }

        public enum CompareResult
        {
            Less,
            Equal,
            Greater,
        }

        public enum GraphSearchStatus
        {
            Continue,
            Break,
            Goal,
        }

        public class Node<NodeType, Value>
        {
            public NodeType This;
            public Node<NodeType, Value> Previous;
            public Value Priority;
            public Value Cost;
            public Node<NodeType, Value> Next;
        }
    }

    #endregion
}

Notes

• There are currently no ways to set default values for generic arguments in C#. When methods have a lot of generic parameters, every single one of those generic parameters would need to be supplied on every usage. There may be ways to add default/optional logic to generic parameters, but I haven't explored that topic yet.

• This style of code can result in the need to pass in duplicate generic parameters into the same function. For example, the BinomialCoefficient method in the provided examples would require duplicate usage of the Multiplication generic parameter (once for the BinomialCoefficient method and once for the embedded Factorial method). There may be workarounds for this necessity, but I haven't explored that topic yet.

[ZacharyPatten]

This feature does not require default generic parameters to be useful.

However, if default generic parameters are possible it would be immensely helpful for this feature. So, I wanted to make a half-baked attempt at what default generic parameters could look like. Hopefully there is a better option than this, because this is more-or-less a straight up hidden macro, and macros are usually considered blasphemy in the realm of C#.

Half-Baked Default Generics Concept [click to expand]

using DefaultGenericParameters; // <- exposes default generics to the file

namespace DefaultGenericParameters
{
	// If the name of any generic parameter matches the name of
	// this default generic and they share the same method
	// signature (including the return type), then the compiler
	// would map to this function if no explicit override was
	// provided. The visibility of these default generics should 
	// be namespace restricted. They are more-or-less straight
	// up macros.
	
	default generic Addition [int method(int a, int b)] => a + b;
	
	default generic Addition [float method(float a, float b)] => a + b;
	
	default generic Zero [int method()] => 0;
	
	default generic Zero [float method()] => 0;
}

namespace A
{
	public static class ExampleClass
	{
		public static T Summation<T, Addition, Zero>(params IEnumerable<T> iEnumerable)
			where Addition : [T method(T, T)]
			where Zero     : [T method()]
		{
			T result = Zero();
			foreach (T value in iEnumerable)
			{
				result = Addition(result, value);
			}
			return result;
		}
		
		public static ExampleMethod
		{
			int[] array = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, };
			
			// The default generic parameters applied.
			int a = Summation(array); // <- will compile
			
			// You could override the default generic parameters by explicitly
			// providing your own. Note: the "override" in this case is simply
			// a copy-paste of the default because this is too simple of an
			// example (there isn't really an alternative to adding integers).
			int b = Summation<
				Addition: { (a, b) => a + b },
				Zero: { () => 0 }>(array); // <- will compile
				
			// An example of a meaningful override could be an "IsInteger"
			// function. If a default IsInteger function (for whatever reason)
			// was "(int a) => a % 1 == 0" that could be optimized to
			// "(int a) => true" by the calling code since int types 
			// will always be integers, which could be further optimized
			// considering this would be JIT-ed.
			
			// Another meaningful override could be swapping out trig
			// functions. You could write an approximated "sin" function
			// that is faster than "Math.Sin" (but probably less accurate)
			// if you needed to speed up a calculation.
		}
	}
}

namespace B
{
	// If there happen to be multiple default generic definitions that
	// match a generic parameter in the current scope, the compiler
	// should break and force an override to be explicitely provided.

	default generic Addition [int method(int a, int b)] => a + b;

	public static class ExampleClass
	{
		public static ExampleMethod
		{
			int[] array = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, };
			
			int a = A.ExampleClass.Summation(array); // <- will not compile
			
			int b = A.ExampleClass.Summation<Addition: { (a, b) => a + b }>(array); // <- will compile
		}
	}
}

namespace C
{
	// It might be a good idea to dis-allow defining default
	// generics in the same namespace as a method they would be
	// applied to, because then there would be no means of
	// overriding it for the relative method(s) while "using"
	// that namespace.

	default generic Addition [int method(int a, int b)] => a + b; // <- will not compile?

	public static class ExampleClass
	{
		public static T Summation<T, Addition, Zero>(params IEnumerable<T> iEnumerable)
			where Addition : [T method(T, T)]
			where Zero     : [T method()]
		{
			T result = Zero();
			foreach (T value in iEnumerable)
			{
				result = Addition(result, value);
			}
			return result;
		}
	}
}

Regardless of this concept being potentially impossible or too blasphemous, I hope that it illistrates how powerful default generics could be if used along-side this feature. Having defaults to simplify the syntax while maintaining the ability to override individual components on each invocation of the same member (prior to JIT) would be very nice. Or... maybe I'm just drunk... :D

[amoerie]

I think I see the benefits of what you’re suggesting here, but it feels like a whole lot of work just because methods cannot be declared outside classes in C#. Static classes with static methods and then consuming them with static imports comes closest, but - as your proposal aptly demonstrates - methods are not first class top level constructs.

To be clear, I love the possibilities that this proposal would enable (real functors and all sorts of wonderful things from FP land!) but I’m not convinced this proposal is the best way to get there.

[ZacharyPatten]

@amoerie I think you might be miss-interpreting the intent of the proposal. It has nothing to do with the inability to place methods outside of classes. It is an optimization that will essentially allow static function pointers to be resolved at compile time (rather than runtime via delegates). Any time you write a lambda expression that does not contain capture variables (meaning it could be made static) or pass in references to static methods, it may be able to be resolved at compile time rather than runtime by moving the lambda from being a normal method parameter to being a generic parameter on the method. If a generic parameter is a struct it is optimized by the JIT via reification.

[Joe4evr]

Sounds like you have a lot of overlap with the proposal of "static delegates", see also: #302.

[ZacharyPatten]

@Joe4evr There appears to be somewhat similar intent between this and "static delegates." However, if I am not mistaken static delegates are still a runtime concept. Static delegates will never allow for compile time in-lining and optimization as this proposal would, but static delegates would be objects at runtime while this proposal would have no runtime object.

So... Although they share similar intent, they are seperate features with completely seperate use cases (runtime vs compile time). If possible, you would always want to use this approach over static delegates, but you won't always be able to. A good example is events. Static delegates could be moved around and redirected at runtime while this feature could not (like what happens in runtime event driven systems).

[mattwar]

This is an interesting idea. It would take a lot of runtime change / support to make work.

[reflectronic]

The proposed implementation is pure lowering into a struct with the method in it. Runtime changes aren’t needed for this (although it is still an option).

[HaloFour]

A lot of this sounds like it would fall under the "shapes" proposals. If delegates could match to the shape of an interface with a single Invoke method then perhaps lambdas syntax could be extended to support those shapes as well. Then the BCL could define a handful of these interfaces, as it does with Action<...> and Func<...> today, allowing for the developer to define their own for more "exotic" signatures.

[ZacharyPatten]

@HaloFour You won't be surprised to hear that I started working on this immediately after hearing about shapes.

Shapes are not a feature yet so I don't know what they will be like, but I was worried about overridability. If I just want to override one method in a shape, am I going to have to make an entirely new shape to do that? If I want to make a custom "BinomialCoefficient" shape will I have to start from ground zero and reimplement all the lower components too? Idk... The approach in this issue lets me mix-and-match all the inner components of a method with seemingling minimal redundancy (especially if default generics are possible).

Also... I really like the lambda style syntax...

[HaloFour]

@ZacharyPatten

Shapes are not a feature yet so I don't know what they will be like,

Neither do I, but at least one common theme has been compiler-emitted implementation via a witness struct.

I just want to override one method in a shape, am I going to have to make an entirely new shape to do that?

As it stands, probably. But if a delegate/lambda could be considered by the compiler to meet the requirements of the shape I think that would enable the behavior you're looking for through very similar syntax, although using the named shape instead of a method signature. As for defining the shapes, I think the helper shapes/interfaces like IAction would cover the majority of use cases, but we're not going to see the BCL add new types for every permutation of signature (arity, ref, out, in, etc.), so that capability would still need to be available to the developer.

Either way I think it's worth seeing where delegates/lambdas fit in the world of shapes, if at all.

[YairHalberstadt]

Related: #2482

[ZacharyPatten]

@YairHalberstadt This is off topic, but...

Off Topic Comments [click to expand]

From my experience I have personally found that passing in the functionality is better than passing out the values. Passing in the functionality can still allow for breaking iteration, but it requires additional code to do so. A great example of this is an AVL tree. An AVL tree is a recursive data structure that does not require a parent pointer. Without a pointer to parents, you would be required to use heap-allocated stacks for iteration if you wanted to use the IEnumerable<T> pattern. Instead, passing in the functionality works perfectly fine with recursive data structures and it is just passed around with the recursion. Anymore... I find myself avoiding IEnumerable<T> if at all possible.

https://gist.github.com/ZacharyPatten/aa5f923c383334b76a43c94fc530ec87

Note: If the feature in this issue became reality I would update that gist with examples using this issue's methodology.

[ZacharyPatten]

@HaloFour I agree that shapes could allow for similar functionality, but should they? I was hoping to get a comment out of you about default generics. I fully realize how polarizing of a feature that would be, but in my opinion it is too useful to not consider in C#. I almost made an issue for it already, but I was worried people would miss understand. If default generics were a thing, it would almost be like automatic shapes, and I imagine I would rarely (if ever) need to explicitly write a shape.

Shapes appear to group functions into containers so you don't have to provide all the underlaying functionality.

Default generics would allow the compiler to look up functionality so it would never have to be grouped in the first place.

Obviously... Shapes have me worried and I think they might be a huge mistake. Hopefully I'm wrong.

[HaloFour]

@ZacharyPatten

I agree that shapes could allow for similar finctionality, but should they?

Why have two completely different features for a group of 1 action vs. n actions? You still need named types to serve as containers, whether they be supplied by the BCL or the developer. You have very similar if not identical code generation.

Default generics would allow the compiler to look up functionality so it would never have to be grouped in the first place.

Seems like a much more complicated syntax for writing extensions. Your proposal doesn't describe where these "default generics" live as metadata or how the compiler wires them up. IMO extending "extension members" to support more scenarios and then allowing those extensions to participate with "shapes" is a more elegant solution.

But that's just my opinion. Shapes still seem quite early in their design and the discussions posted so far by the team have explored a couple of different approaches. I'd say that they'd probably welcome more data to inform their design process.

#1711
#164
https://github.com/MattWindsor91/roslyn/blob/master/concepts/docs/csconcepts.md

[ZacharyPatten]

Note: I briefly discuss "default generics" in the first comment of this issue, but it is currently little more than a passing thought.

[HaloFour]

@ZacharyPatten

But ignoring all that... How exactly would this feature work if backed by shapes?

No extension would be required. The compiler would emit the witness struct that wraps the delegate and implements the "shape". Something like this:

// the shape
public interface IAdder {
    int Invoke(int x, int y);
}

static class Program {
    static int Add2<T>(int x, T adder) where T : IAdder => adder.Invoke(x, 2);

    static void Main() {
        var result = Add2(2, (x, y) => x + y);

        // compiles into
        Func<int, int, int> func = (x, y) => x + y;
        Adder_FuncWitness witness = new Adder_FuncWitness(func);
        M<Adder_FuncWitness>(witness);
    }

    private struct Adder_FuncWitness : IAdder {
        private readonly Func<int, int, int> func;

        public Adder_FuncWitness(Func<int, int, int> func) => this.func = func;

        int IAdder.Invoke(int x, int y) => func.Invoke(x, y);
    }
}

Theoretically, anyway. The compiler is (probably) already going to do this for types that implicitly match the shape. Extensions are only necessary if the type doesn't match the shape and you need to fill in some of the other members.

The questions would be whether the delegate, which has an Invoke method already, would match a shape with an Invoke method, and whether or not the compiler could target-type the lambda into the shape directly.

Maybe, maybe not, but it looks like it's so close already.

And yes, there is an extra allocation in the above code if you run it on the runtime today. Part of the design of shapes is looking into runtime changes that would eliminate that allocation. Otherwise the generics would have to get a bit weird.

[ZacharyPatten]

I just want to clarify that there should never be a runtime delegate. That would defeat the entire purpose of this feature as it would not resolve at compile time. I assume you added that just for demonstration purposes, and that you don't expect a delegate at runtime.

---

@HaloFour

If I am not mistaken, what you have just sugguested is for the ability to override extensions, because for these conditions the compiler would not look for extensions as one would be explicitly provided.

The problem with this is that you would only be able to override extensions of shapes with single "Invoke" methods. No other extensions would be overridable unless the syntax allows for much more complicated generic argument code that allowed for multiple members to be included in a single generic argument (allowing the override of extensions with multiple members).

1. Only allowing the overriding of compliant extensions is not a good idea.
2. (In my opinion) Allowing overriding of multi-membered extensions would be potentially very ugly code and likely be encouraging antipatterns.

[HaloFour]

@ZacharyPatten

should never be a runtime delegate

It's possible that the compiler could emit a shape implementation directly from the lambda without a delegate in the mix. However, members of the team have already expressed that they're not interested in doing stuff like functional interfaces, so I don't really think that's as likely to happen.

The problem with this is that you would only be able to override extensions of shapes with single "Invoke" methods.

I'm not sure what this means. Shapes don't rely on extensions unless the type in question doesn't match the shape, in which case you can use extensions to fill in the missing members. In this case the delegate (or whatever) would match the shape and no extensions would be necessary.

[ZacharyPatten]

@HaloFour

Correct me if I'm wrong, but wouldn't this example demonstrate that using shapes as the backing mechanism for the "compile-time-lambdas" described in this issue would be overriding extensions?

public shape AddShape<T>
{
    static T Add(T a, T b);
}

// this extension would be overrided by the lambda
public extension IntAdd of int : AddShape<int>
{
    public static static int Add(int a, int b) => a + b;
}

public static Summation<T, AddMethod>(params T[] values) where AddMethod : AddShape<T>
{
    T summation = default; // Note: assume default will be zero for this example
    foreach (T value in values)
    {
        summation = AddMethod.Add(summation, value);
    }
    return summation;
}

public static void Main()
{
    int[] values = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, };

    Summation<int, { (a, b) => a - b } >(values); // uses lambda

    // Note: If this will not be possible with shapes, then this issue is likely a completely
    // separate feature:
    Summation(values); // uses the "IntAdd" extension
}

---

... I don't really think that's as likely to happen.

Refusing to allow in-line no-overhead abstractions (as described by this issue) to the language is a huge mistake.

Although the content of this issue would compile to an interface, there would be no user defined "functional interface." It would be achieved with constraints on the generics instead.

[HaloFour]

@ZacharyPatten

Correct me if I'm wrong, but wouldn't this example demonstrate that using shapes as the backing mechanism for the "compile-time-lambdas" described in this issue would be overriding extensions?

I'm suggesting that the lambda match the shape directly, thus not require any extensions. You'd need an extension if you specifically wanted an Add method and needed int to implement it. But if the shape specified an + operator int should already work. If the shape had an Invoke method theoretically any delegate with a compatible signature would work.

Refusing to allow in-line no-overhead abstractions (as described by this issue) to the language is a huge mistake.

Shapes are expected to be a no-overhead abstraction.

Although the content of this issue would compile to an interface, there would be no user defined "functional interface." It would be achieved with constraints on the generics instead.

IMO having the compiler spit out a public interface is itself a problem. Everything about that generated interface has to be a part of the C# specification so that different versions/implementations of the compile emit binary compatible versions of the interface, otherwise a recompilation could completely break code. On top of that, there is no signature equivalence between different implementations of the same signature, so two parts of a project with identical method constraints would produce incompatible interfaces. This is already a problem with delegates. Having proper named types eliminates all of these concerns and simplifies everything massively.

[ZacharyPatten]

@HaloFour

I'm suggesting that the lambda match the shape directly, thus not require any extensions. You'd need an extension if you specifically wanted an Add method and needed int to implement it. But if the shape specified an + operator int should already work. If the shape had an Invoke method theoretically any delegate with a compatible signature would work.

I don't understand what you mean by "match the shape directly." If you mean that all the functionality should be lumped into one generic parameter... that is exactly the problem I'm worried about. What about all the examples I have provided with multiple generic parameters? All of them are overridable. You can make a different graph in the GraphSearchExample and run the graph search algorithm on it and my example in the same code. If all the functionality is in one generic parameter, how will you override components?

---

Most of your other comments appear to simply be worries about complexity. I never said this feature would be easy to implement.

[HaloFour]

If you mean that all the functionality should be lumped into one generic parameter... that is exactly the problem I'm worried about.

No, you could have a generic parameter per shape per single operation/lambda. Or you could have them all in one. Or a combination thereof.

I'll note that for non-capturing lambdas the compiler already caches a single instance, so you have the overhead of a single allocation once for the life of the program.

Most of your other comments appear to simply be worries about complexity.

No, it's that this feels like it's already 95% covered by shapes, and it makes more sense to look at how shapes can fit this functionality rather than coming up with something completely different. But if that something different is also quite a bit more complex it has to justify that complexity against a simpler implementation that fits in with an existing language feature (or existing proposals/directions that already have a strong backing by the team).

[gafter]

This looks like #110 but structural instead of nominal, and with a different syntax.

[ZacharyPatten]

This looks like #110 but structural instead of nominal, and with a different syntax.

@gafter There are some differences, but, I agree, that is fairly accurate.

[ZacharyPatten]

I just want to mention that this feature could even help with such a trivial thing as sorting arrays. The Array.Sort<T>(T[], Comparison<T>) and Array.Sort<T>(T[], IComparer<T>) are not as fast as using structs.

Here are some benchmarks if anyone is interested: https://zacharypatten.github.io/Towel/articles/benchmarks.html#sorting-algorithms

I didn't even replicate the System.Array.Sort algorithm yet, but even the basic Quick and Merge sort algorithms are faster than either of the aforementioned System.Array.Sort methods when you use structs instead of delegates or unconstrained IComparer's for at least up to N ~ 10000 (I did not benchmark further than that yet).

[john-h-k]

Seems easier for the JIT to improve its skill at de-indirecting delegate calls no?

[ZacharyPatten]

@john-h-k I'm by no means an expert at the JIT. I think most of the of the optimizations this issue covers could be implemented via JIT optimizations, but I'm not sure. Even if they are possible via JIT though, that would be a huge change that I could see it breaking many tools out there. But, I would agree that it should be added to the JIT sometime in the future.

I'm still very much exploring this topic myself. I could be wrong, but I imagine that there are cases in which the JIT cannot optimize the code by itself. For example... It would be awesome if you could define method constraints with method constraint parameters:

public static void Method<T, Stepper>()
	where Stepper : [void method([void method(T)])]
{
	// code
}

I imagine that would potentially generate 2 interfaces. I'm not sure if this is possible yet, but if it is, I definitely have use cases for it. It is similar to the following (which is currently possible):

public static void Method<T>(Action<Action<T>> stepper)
{
	// code
}

I may be wrong, but I don't think it would be possible for the JIT to inline both of those Action<>'s (Action<Action<T>> & Action<T>) even if both are assigned to static methods without adding overhead branching logic.

[dmitriyse]

FYI there are two very related proposals:
One on C# Compiler level: #1413
Another one on JIT level: dotnet/runtime#10049

[ZacharyPatten]

@dmitriyse Yeah they are definitely related.

If I understand #1413 correctly, you are proposing attributes to inline delegates. Personally I don't think that attributes are a good solution in comparison to syntax changes (as in this issue). There would have to be a lot of extra restrictions like you could only ever invoke the delegate (nothing else, including stuff like optional parameters on the delegate) or the method should not compile with that attribute (since the delegate is intended not to exist). Also, attributes would not work with well lambda expressions or at least result in rather ugly code in my opinion.

[ZacharyPatten]

@HaloFour @gafter @CyrusNajmabadi
After a discussion with Cyrus on this topic (and as HaloFour mentioned in the comments above), this style of syntax could likely be incorporated into Shapes.

As for the argument of nominal vs structural... as long as shape A could be used/passed into a member as shape B if they share the same structure, then I see no reason the not choose the nominal approach of the proposed "Shapes" over the structural approach I defined in this issue.

I just really want the LDM to keep lambda style syntax in mind while designing Shapes. I haven't seen any mention of lambda style syntax with shapes yet (granted I'm not involved in the discussions of course), and that is why I opened this issue in the first place. The "lambda" for Shapes would likely go in the normal parameter location rather than the generic arguments, which would be much cleaner syntax.

If lambda style syntax is confirmed for Shapes, this issue should be closed.