为什么这个继承的属性表达式对于编译器来说是模棱两可的？

问题描述

考虑以下代码：

using System;

namespace Sample
{
    public interface IGetOptions
    {
        string Options { get; }
    }

    public interface ISetOptions
    {
        string Options { set; }
    }

    public interface IOptions : IGetOptions,ISetOptions
    {
    }

    public class MyOptions : IOptions
    {
        public string Options { get; set; }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            var a = new MyOptions();
            DoIt(a);
            Console.WriteLine(a.Options);
        }

        private static void DoIt(IOptions x)
        {
            x.Options = "test"; // Ambiguity between IGetOptions.Options and ISetOptions.Options
        }
    }
}

我一直将属性理解为返回值或分配值的方法的语法糖。假设IGetOptions和ISetOptions之间的冲突仅按名称存在，并且每个接口都定义了get或set，为什么编译器无法解析上面的歧义？

对我来说，很明显应该在此处调用ISetOptions.set_Options。如果要按以下方式更改代码，则可以正常编译：

public interface IGetOptions
{
    string Options();
}

public interface ISetOptions
{
    void Options(string value);
}

public interface IOptions : IGetOptions,ISetOptions
{
}

public class MyOptions : IOptions
{
    public string Options() { return _options; }

    public void Options(string value) { _options = value; }

    private string _options;
}

public class Program
{
    public static void Main(string[] args)
    {
        var a = new MyOptions();
        DoIt(a);
        Console.WriteLine(a.Options());
    }

    private static void DoIt(IOptions x)
    {
        x.Options("test");
    }
}

这是我一直以来都了解的带有属性的事情，那么为什么编译器不能为我做出这种跳跃？

我还意识到（我认为）一种解决方法是使用new关键字隐藏继承的属性。使用我发布的第一个代码段，对IOptions进行的以下更改使代码可以按预期方式编译和运行：

public interface IOptions : IGetOptions,ISetOptions
{
    new string Options { get; set; }
}

这对我也很好奇。当然，我从未故意使用new隐藏继承的属性或方法，但是我认为这意味着IOptions.Options在物理上与IGetOptions.Options不同，这意味着接受IGetOptions的方法并且如果同一对象也是Options，则求值IOptions.Options不会和IOptions看到相同的事物。所以这里的问题是：编译器如何足够聪明地折叠并关联在名称上发生冲突的继承属性，但又不足以解决上面的歧义？

预先感谢，如果需要澄清，请告诉我。

解决方法

C＃语言规范确实描述了“方法组”的概念，从而允许编译器根据其他条件延迟从一组候选对象中选择单个方法的过程。

但是语言规范目前对于属性组没有类似的概念。即使{name {name}操作的结果与使用哪个nameof(IOptions.Options)属性相同，您也会遇到Options的错误。

为什么编译器不能消除这些属性的歧义？简短的答案是因为事实并非如此。现在，编译器希望将属性名称解析为单个属性，而无需关心该属性的使用方式。一个简单，可测试的过程，足以满足开发人员的当前需求。

如果要向编译器添加支持，则需要记录语言规范将如何更改，然后说明编译器的各个组件将如何更改。从其他编译器工程师那里获得支持，并说服他们所有这些额外的复杂性都是必要的。然后实施这些更改并编写单元测试以确认其工作原理……而目前为止还没有人这样做。