[Proposal] Allow Implicit Conversions from Lambda Expressions to User-Defined Types

[fitdev]

As is explained in this StackOverflow question, it would be really nice that given a user defined type:

public readonly ref struct ValOrFunc<T> {
  readonly T _value;
  readonly Func<T> _func;

  public ValOrFunc(in T value) { _value = value; _func = null; }
  public ValOrFunc(in Func<T> func) { _func = func; _value = default; }

  public static implicit operator ValOrFunc<T>(T it) => new ValOrFunc<T>(it);
  public static implicit operator ValOrFunc<T>(Func<T> it) => new ValOrFunc<T>(it);
}

And say a method:

static void SomeMethod<T>(ValOrFunc<T> it) { /* do something here */ }

It should be possible to utilize this type like so:

SomeMethod(() => new SomeType());

However, as of C# 7.3 the above won't compile and instead an explicit, ugly-looking cast is required:

SomeMethod((ValOrFunc<SomeType>)(() => new SomeType()));

[gafter]

This would be a breaking change because it could change the overload resolution result for method calls in existing code.

[fitdev]

@gafter Oh that's a bummer! It would however simplify a lot of code, and basically open the road for easy usage of user-defined types that combine delegate and non-delegate types like the example above. Perhaps you can make it opt-in via a switch (after all you guys said you will already be introducing a switch for Null reference types).
Compatibility is of course critical, but at the same time it can be preserved with compatibility switches, while at the same time allowing you to move the language forward, making it more practical and effective (by requiring less keystrokes for instance).

EDIT 1 :
Just as an example, right now in my code I need to have 2 overloads for various methods that accept exceptions as parameters: one for plain Exception as a parameter, and the other for Func<Exception>. This is needed because it is not guaranteed that the actual parameter will be used (i.e. throw an exception), therefore more often than not it's better off to pass a Func rather than instantiate the object (ok, exceptions are cheap to instantiate in general, but other objects may not be).
Thus, if you have a proxy user type: ExOrFuncOfEx<T> where T: Exception { ... }, now you need just a single method overload accepting ExOrFuncOfEx<T> as a parameter, which you can elegantly call by passing it either an actual object (exception in this case) or a lambda. Requiring an explicit cast to Func<T> for all cases where lambda would be passed makes this approach impractical (too much work for the consumer of the method).

EDIT 2:
I don't quite see how that would be a breaking change though. Since today you are required to do an explicit cast, all the explicit casts are already there, and you would simply be lifting that requirement only for cases where implicit operator is defined for precisely the correct type of Func. Is there much code in existence that defines an implicit operator for casting user-defined types from Funcs? I doubt it, since effectively, as of today that operator is useless, because an explicit cast is always needed (so if anything the operator that could be encountered in codebases out there would be an explicit one).

[theunrepentantgeek]

The introduction if a switch for null reference types is very much the exception that proves the rule - they've been extremely clear about their desire to avoid splintering the language into multiple dialects. The only reason null references get a pass - and a switch - is due to their extremely high value.

by requiring less keystrokes for instance

In my opinion, fewer keystrokes is not a reason to evolve the language - code is read much more than it is written. Conciseness is important because it makes the code easier to read, not easier to write.

[gafter]

The null reference type feature does not affect the meaning of code, it only produces warnings.