Overloads with usage location restriction - for source generation scenarios

[ymassad]

Consider the following non-generated code:

public static class Program
{
	public static void Main()
	{
		
	}
	
	public static ILogger logger LoggingSystem.CreateLogger();
	
	public static void Method1(int p1)
	{
		int v1 = 15;
		int v2 = Calc1();
		
		logger.Log(p1, v1, v2);
	}
	
	public static int Calc1() => 2;
}

And the following generated code (by a source generator):

public static class LoggerExtensions1
{
	[OverloadRestrictedTo(file: ".\main.cs", line: 14, column: 8)]
	public static void Log(this ILogger logger, int p1, int v1, int v2)
	{
		logger.WriteLine($"Method: Method1, p1 parameter: {p1}, v1 variable: {v1}, v2 variable (result of calling Calc1): {v2}"); 
	}
}

This allows a special implementation for each invocation of Log based on the "environment" of the invocation. Even if the parameter names and types are the same for two invocations, we can generate two extension classes each with one extension method. Because of the OverloadRestrictedTo attribute, the compiler has no problem knowing which overload to use.

UPDATE: I discovered that the following is not really a usage scenario for the suggested feature (it can be done with source generators alone). Please ignore it. I keep it to make comments below understandable.

As another usage scenario, this can also be used to return concrete types for different input types, e.g.:

ConcreteTypeForPerson c1 = OfType<Person>().DoSomething();
ConcreteTypeForCar c2 = OfType<Car>().DoSomething();

c1.SpecialMethodForPerson();
c2.SpecialMethodForCar();

For example, this can be used with fakes in unit testing:

public interface IService
{
    void Method1();
    void Method2(int a);
}

var fake = OfType<IService>().Fake(); //the type of fake is a concrete FakeForIService class

//Use fake here...

//Then access invocations

var method1Invocations = fake.InvocationsOfMethod1();

var method2Invocations = fake.InvocationsOfMethod2();

var method2Invocation1 = method2Invocations[0]; //Type of method2Invocation1 is FakeForIService.Method2Type.Invocation

Assert.AreEqual(3, method2Invocation1.Parameters.a);

[Joe4evr]

Sounds like something you can accomplish with a custom analyzer.

[ymassad]

I can't see how. Can you explain?

[YairHalberstadt]

Can you think of any scenarios where this would be useful other than for this very specific scenario? In most cases I think CallerMemberNameAttribute should be sufficient.

Also note your current design wouldn't work if there were multiple calls to log in the same method. That seems quite limited.

[ymassad]

I can see how this might bring support to the first use scenario. But not the second. In the second scenario, you need the return types of the two extension methods to be different.

[YairHalberstadt]

I'm not sure I understand the fakes scenario. Could you show the generated code please?

[ymassad]

Non generated code utility code:

public class TypeClass<T>{}

public static class Utils
{
	public static TypeClass<T> OfType<T>() => new TypeClass<T>();
}

Generated code for the example above:

public static class ExtensionClass1
{
	public class FakeForIService : IService
	{
		public class Method1Type
		{
			public class Invocation
			{
				public class Parameters
				{
					
				}
			}
		}
		
		public class Method2Type
		{
			public class Invocation
			{
				public class Parameters
				{
					public int a {get;}
					//ctor
				}
			}		
		}
		
		public Method2Type.Invocation[] GetInvocationsForMethod2()
		{
			//...
		}
	}
	
	public static FakeForIService Fake(this TypeClass<IService> tc)
	{
		return new FakeForIService();
	}
}

Once I wrote the code, I realized that this suggested feature is not required in this case. My real use case is a mix of both cases (e.g. example1 and example2 in the post). But my real use case is very specialized to use as motivation for this feature.

[ymassad]

To explain more, my real use case requires the return type of generated methods to be different depending not just on the input types (like TypeClass<IService>) but also on the "environment" of the call site.

[CyrusNajmabadi]

but also on the "environment" of the call site.

The only way to do this would be to have the call site have an actually different environment. I.e. a different set of usings that bring in different extensions.

I cannot envision a world where we would allow code to have the same environment but have that end up calling different methods.

[amis92]

Generally, you can already attempt to do this today with the "hide-to-rewrite" approach many source generation scenarios take to "rewrite" user code.

1. Your Method1 would look like the following:

[CustomLogRewrite]
static void Method1Core(int p1)
{
	int v1 = 15;
	int v2 = Calc1();
	
	logger.Log(p1, v1, v2);
}

2. Your generator generates the following:

static void Method1(int p1)
{
	int v1 = 15;
	int v2 = Calc1();
	
	logger.WriteLine($"Method: Method1, p1 parameter: {p1}, v1 variable: {v1}, v2 variable (result of calling Calc1): {v2}");
}

3. You code still calls Method1, and Method1Core is never used except for being rewritten.

Of course it's neither pretty nor expandable (you can only have one generator "overwrite" your method), but it's something you can do today.

[ymassad]

How would logger.Log(p1, v1, v2); compile in Method1Core?

[amis92]

Well for one, it doesn't have to if for example you surround the method with #if CUSTOM_LOG_REWRITE, but it's very poor experience.

I guess you can just introduce (via source generator) an extension method like

internal static void Log(this ILogger @this, params object[] args) => throw new NotSupportedException();

[CyrusNajmabadi]

I can see how this might bring support to the first use scenario. But not the second.

In your post, you say that the second scenario no longer applies. So it sounds like there is a solution for the first scenario already possible with our CallerXxx attributes.