为什么键入推理和隐式运算符在以下情况下不起作用？ [英] Why type inference and implicit operator is not working in the following situations?

问题描述

  class V< T> 
 {
 public readonly Func< T>得到; 
 public readonly bool IsConstant; 
 
 V（Func< T> get，bool isConstant）
 {
 Get = get; 
 IsConstant = isConstant; 
 
 
 public static implicit operator V< T>（T value）
 {
 return new V< T>（（）=> value，true） ; 
 
 
 public static implicit operator V< T>（Func< T> getter）
 {
 return new V< T>（getter，false）; 
 
 
 
 void DoSomething< T>（V< v> v）
 {
 // ... 
} 
 
 void Main（）
 {
 DoSomething< string>（test）; //（1）类型推断不起作用
 DoSomething< string>（（（V< string>）（（）=>test））; //（2）隐式运算符不起作用
} 
  

在 Main ，我有两种情况：

1. 我必须明确指定泛型参数到方法 DoSomething 。


2. 在这里，我必须添加显式转换（V< string>），隐式运算符似乎不起作用。
   

为什么这是必需的？第二个问题是为什么隐式转换的原因是什么？从（）=>到 V< string> 不会成功，即使（）=>可转换为 Func< string> 和 Func< string> 可转换为 V< string> 。



再一次，我不知道如何回答为什么不呢？但我确实知道如何回答规范的哪一行表明编译器应该拒绝此代码？的问题。相关的行是：



首先，如果需要，执行从源类型到用户定义或操作数类型的标准转换取消转换操作符。

请注意，这里有一个小错误;这应该说从源表达式执行标准转换。源表达式可能没有类型。我相信在我离开团队之前，我已将这张纸条交给了规格维护者，所以希望这个规格能在下一版中得到修复。

无论如何，现在应该清楚正在这里。没有从lambda到委托类型的标准转换，因此用户定义的转换被转换分辨率算法归类为不适用。

I will try to explain my question on an example:

class V<T>
{
    public readonly Func<T> Get;
    public readonly bool IsConstant;

    V(Func<T> get, bool isConstant)
    {
        Get = get;
        IsConstant = isConstant;
    }

    public static implicit operator V<T>(T value)
    {
        return new V<T>(() => value, true);
    }

    public static implicit operator V<T>(Func<T> getter)
    {
        return new V<T>(getter, false);
    }
}

void DoSomething<T>(V<T> v)
{
    //...
}

void Main()
{
    DoSomething<string>("test"); // (1) type inference is not working
    DoSomething<string>((V<string>)(() => "test")); // (2) implicit operator does not work
}

In the method Main, I have two situations:

1. I have to explicitly specify the generic argument <string> to the method DoSomething.
2. Here, I have to add the explicit cast (V<string>), the implicit operator does not seem to work.

Why is this required? What the alternatives that the compiler is considering, so it cannot choose the correct way?

解决方案

Your second question is why the implicit conversion from ()=>"" to V<string> does not succeed, even though ()=>"" is convertible to Func<string> and Func<string> is convertible to V<string>.

Again, I do not know how to answer "why not?" questions but I do know how to answer the question "what line of the specification indicates that the compiler ought to reject this code?" The relevant line is:

First, if required, performing a standard conversion from the source type to the operand type of the user-defined or lifted conversion operator.

Note that there is a small error here; this should say performing a standard conversion from the source expression. The source expression may not have a type. I believe I gave that note to the spec maintainer before I left the team, so hopefully this will get fixed in the next edition.

Anyway, it should now be clear what is going on here. There is no standard conversion from a lambda to a delegate type, and therefore the user-defined conversion is classified as inapplicable by the conversion resolution algorithm.

这篇关于为什么键入推理和隐式运算符在以下情况下不起作用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！