Visual Studio错误解决方法中的lambda与Func委托重载？

Question

在具有各种Func委托重载的函数中使用匿名方法时,我在Visual Studio 2010中遇到了一些奇怪的行为.

我在下面创建了一个小型复制课程.

考虑这个ListViewAdapter类

namespace LambdaTestApp
{
    public class ListViewAdapter<T>
    {
        private Func<int, string, int, string> _converter1;
        private Func<RefType1, string, string> _converter2;

        public ListViewAdapter(int arg1, Func<int, string, int, string> converter) 
        {
            _converter1 = converter;
        }

        public ListViewAdapter(int arg1, Func<RefType1, string, string> converter) 
        {
            _converter2 = converter;
        }

        public static ListViewAdapter<T> MockPopulate(int arg, Func<int, string, int, string> converter) {

            ListViewAdapter<T> instance = new ListViewAdapter<T>(arg, converter);

            return instance;
        }

        public static ListViewAdapter<T> MockPopulate(int arg, Func<RefType1, string, string> converter)
        {
            ListViewAdapter<T> instance = new ListViewAdapter<T>(arg, converter);
            return instance;
        }
    }

    public class RefType1
    {
        public string Property1 { get; set; }
    }
}

以下代码使用带有lambda的重载:

namespace LambdaTestApp
{
    class Program
    {
        static void Main(string[] args)
        {
            ListViewAdapter<RefType1>.MockPopulate(1, (item, str) =>
            {
                var myItem = item;
                return str;
            });
        }
    }
}

它应该下定决心,Func<RefType1, string, string>和第一个参数应该是RefType1,但是这个问题是不是说item是一个RefType1Visual Studio中看到它作为一个int.

问题:Func代理之间是否存在不明显的有效转换,或者这是Visual Studio IntelliSense错误？

Answer 1

我个人认为这是一个错误 - 或者至少是一个缺陷.即使它仅在代码无效时出现 - 并且只有在lambda表达式中的代码无效时才会显示- 我认为Intellisense更适合查看lambda表达式的参数声明部分(之前的部分=>)为完成,并根据该信息工作.

没有什么可以放在lambda表达式的主体内,这将改变重载分辨率,从而使选择Func<int, string, int, string>有效......只是没有足够的参数.

我至少建议记录一个关于这个问题的连接问题 - 就"MS没有设计它以应对这种情况"而言,它可能是"按预期工作"但它可以明显更好地工作.请注意,它仍然在VS11测试版中以这种方式工作,尽管我现在正在运行的笔记本电脑尚未应用最新版本的测试版.如果你的反应达到了"是的,这会很好 - 但是需要大量的工作才能获得收益",我不会感到惊讶,但无论如何它都值得提升,IMO.