Simplified generic extended method？

[NMSAzulX]

Case 1:

    public static class EntityExtension
    {
        // Here,  T、S And V  are in use.
        public static S Get< T, S, V>(this T instance, V value)  where S: class
        {
            return null;
        }
    }

  var instance = new Foo();


  //Now
  Bar result = instance.Get<Foo, Bar, Baz>(baz); 


  //Expect:
  Bar result = instance.Get(baz); 

Case 2:

    public static class EntityExtension
    {
        // Here,  T、S And V are in use.  W is not in use.
        public static S Get< T, S, V, W>(this T instance, S valueS, V valueV)  where S: class
        {
            return null;
        }
    }

  var instance = new Foo();


  //Now
  Bar result = instance.Get<Foo, Bar, Baz, Qux>(bar, baz); 


  //Expect:
  Bar result = instance.Get<Qux>(bar, baz); 

[canton7]

Does this have anything to do with extension methods? Surely it applies to methods generally?

[spydacarnage]

@canton7 - not the OP, but I have noticed that generics in extension methods can be more of a pain.

For instance, an instance method in a generic class, versus an extension method of the same class:

public class Example<T>
{
    public TResult InstanceMethod<TResult>() => return default(TResult);
}

public static class ExampleExtensions
{
    public static TResult ExtensionMethod<T, TResult>(this T example) => return default(TResult);
}

To call these methods, because the compiler can't certain what type TResult is, you need to specify the types (luckily, the compiler is pretty good at predicting, so this doesn't happen all the time):

var example = new Example<int>();
var result1 = example.InstanceMethod<string>();
var result2 = example.ExtensionMethod<int, string>();

Having to include int at the point of evocation, even though that is obvious, can get annoying. Being able to only specify the unknown types would certainly be nicer, and I believe that is what the OP is trying to ask for.

[NMSAzulX]

@spydacarnage Yes. Thank you. I've put up with this for a long time.

@canton7 I think this is faster than waiting for some of the features of AOP. And it will bring more convenience. I shouldn't say too much off the subject. I just think generics need to be evolved.

If possible, perhaps this requires an investigation.

[HaloFour]

I think this somewhat falls under this proposal:

#92

[spydacarnage]

@HaloFour - so, would you expect, under #92, that the following (based on my previous code) would compile correctly?

string result1 = example.InstanceMethod();
string result2 = example.ExtensionMethod();

Because if so, that alleviates 99% of my problem, assuming the level of type inference will extend upwards sometimes? For instance:

private int example = 5;
public string Result() => example.InstanceMethod();

[HaloFour]

@spydacarnage

I think so, yes. I don't spell it out in such specific terms but effectively if the method has a generic type parameter that is used only for the return type of the method and the result of that method is used in an assignment then the compiler would use the type of that assignment to infer the generic type parameter. The type to which the result is assigned would have to be unambiguous, though.

[spydacarnage]

@HaloFour
Sounds great - thanks.

[NMSAzulX]

Does anyone label this Issue?
Does anyone label this Issue?
Does anyone label this Issue?

[NMSAzulX]

@canton7 @spydacarnage @HaloFour I have fix the case code above. Do I need to go to Roslyn or Coreclr to mention something like this Issue?