C# 預設介面方法更新完成，很多細節問題尚待解決

隨著對預設介面方法的支援越來越接近完成，一些潛在的問題被提了出來。雖然已經完成了很多工作，但這是一個複雜的特性，許多細節問題還沒有解決。但首先，這裡有一些已解決的問題。

介面允許使用 static 和 const 欄位了。

除 == 和!= 之外的運運算元也可以在介面中實現。在類中定義的運運算元總是優先於介面中定義的運運算元，即使介面中定義的運運算元更具體。同樣，介面中適用的運運算元會改寫基介面中的運運算元。

現在，在呼叫基類方法時可以跳過類了，下麵這段話證實了這一點：

我們認為，我們已經批准使用新的 base(Type) 語法，其中，Type 是型別別（例如，跳過一個基類並呼叫基類的基類），但是我們應該明確地確認這一點。我們還應該確認 base(Type).M() 可能取用一個非虛成員 M。我們還應該確認一個可訪問性需求：這個查詢找到的 M 必須在呼叫發生的地方可訪問（即通常的名稱查詢約束）。

在介面中宣告受保護方法的特性仍然存在一些疑問，儘管它暫時得到了批准。

當一個類實現了一個方法，但是它的子類將其標記為抽象方法，這被稱為“重新抽象（reabstraction）”。這是 Java 互操作性必需的，但是確切的語法仍然沒有確定。本質上，問題是是否需要 abstract 關鍵字。此外，他們“需要確保執行時 [團隊] 同意實現重新抽象”。

介面中的普通屬性是抽象的，儘管它們看起來像類中自動實現的屬性。但是，如果屬性是靜態的，它就不能是抽象的。這是否意味著在預設情況下，介面中宣告的靜態屬性是自動實現的？

類中的分部方法被認為是私有的，因為它們沒有可訪問性修飾符。但是在介面中，缺少可訪問性修飾符意味著該方法是公共方法。介面中分部方法的規則是什麼？它們允許、不允許還是需要 private 關鍵字？

在預設方法中，object.MemberwiseClone() 是否可以訪問？

最後，是否應該將該特性的正式名稱命名為 RuntimeFeature.DefaultInterfaceImplementation？答：“LDM 並不關心它的名稱。”