c# - C# 和 VB WRT 范围外属性 setter 和 ByRef fn() 参数中的 VB 编译器和/或 IntelliSense 中的错误

Question

我注意到 Visual Studio 2008 (.NET 3.5) 和 Visual Studio 2010 Beta 2 (.NET 4.0) 中存在一些看似奇怪的问题。这些问题也可能存在于以前的版本中。也许它们不是问题，但无论哪种方式，在我提交有关 Microsoft Connect 的报告之前，我都想看看是否有合理的解释。

设置(在 VB 中，C# 结果不同，稍后包含在帖子中):

Public Class SomeClass
    Public Property SomeProperty() As String
        Get
            Return String.Empty
        End Get
        Set(ByVal value As String)
        End Set
    End Property
End Class

Public Class SomeOtherClass
    Public Sub New()
        Dim sc As New SomeClass()
        Me.SomeFunction(sc.SomeProperty)
    End Sub

    ''' <summary>The param as Object fn()</summary> '''
    Public Sub SomeFunction(ByVal param As Object)
    End Sub

    ''' <summary>The param as T fn()</summary> '''
    Public Sub SomeFunction(Of T)(ByRef param As T)
    End Sub
End Class

在这个总结中，从 IntelliSense 的角度来看，Me.SomeFunction(sc.SomeProperty) 调用看起来像这样:

毫不奇怪，这也是在运行时调用的。

所以，我想我的第一个问题是，为什么选择函数的 ByRef 模板化重载版本而不是函数的 ByVal 对象重载版本？我的猜测是编译器和 IntelliSense 只是更喜欢模板化版本而不是非模板化版本。在运行时，实际上调用的是函数的 ByRef 模板化版本。 (这不是缺陷，这只是个人想知道的问题。)

现在，对 SomeProperty 属性稍作更改，使 setter 现在是私有(private)的:

Public Property SomeProperty() As String
    Get
        Return String.Empty
    End Get
    Private Set(ByVal value As String)
    End Set
End Property

一旦您这样做，Me.SomeFunction(sc.SomeProperty) 行就会发生以下情况:

在这种情况下，IntelliSense 建议正在调用函数的 ByVal 对象重载版本，但是错误消息是属性“SomeProperty”的“Set”访问器不可访问，表明编译器仍期望调用 ByRef 模板化版本。所以，这是我的第二个问题。 为什么 Intellisense 声称一件事而 VB 编译器显然在尝试另一件事？ 这对我来说似乎很糟糕。还是我遗漏了什么？

如果不是在 SomeProperty 上使用私有(private) setter，而是将该属性简单地标记为 ReadOnly 并删除 setter 部分，则该函数的 ByRef 模板化版本将显示在 IntelliSense 中并在运行时调用(没有运行时错误)。所以这引出了我的第三个问题，为什么 VB 编译器处理 ByRef 参数的输入对于 ReadOnly 和 not-ReadOnly 的属性不同，但具有超出范围的 setter在 VB 中，就 SomeFunction(Of T)(...) 而言，在其当前范围内，该属性应该就像它是 ReadOnly 一样，我希望它可以调用，就像该属性是事实上只读。但它会产生构建错误。

与问题三相关，执行完全相同的设置(使用 Private setter)，C# 得到了我预期的结果。
在这里，您可以看到 IntelliSense 声称正在调用函数的 SomeFunction(Object) 重载并且没有生成错误。在运行时，实际上调用了 SomeFunction(Object) 版本。那么，为什么在 VB.NET 情况下调用的 SomeFunction(Object) 版本不同？为什么 VB.NET 仍然认为需要调用 SomeFunction(Of T)(ByRef T) 版本？看起来 IntelliSense 在 C# 和 VB.NET 中都正确地确定了它，C# 编译器正在做正确的事情，但 VB.NET 编译器仍然确信它应该调用 ByRef 模板化版本。在我看来，在完全相同的情况下，C# 编译器似乎选择了一个重载，而 VB.NET 编译器选择了不同的重载。我错了吗？

Answer 1

关于第三个问题:

Why is the VB compiler treating the input to ByRef params different for properties that are ReadOnly vs not-ReadOnly, but have an out-of-scope setter in VB

在 CLR 中，不可能将属性作为 ByRef 传递。然而，VB.NET 团队认为这很有用，并实现了一种变通方法。在内部，

Me.SomeFunction(sc.SomeProperty)

转换为

Dim vbTemp = sc.SomeProperty
Me.SomeFunction(vbTemp)

它被称为 Don't Copy Back ByRef 并用于例如只读属性，或者

Dim vbTemp = sc.SomeProperty
Me.SomeFunction(vbTemp)
sc.SomeProperty = vbTemp

它被称为 Copy Back ByRef 并用于同时包含 getter 和 setter 的属性。 jaredpar's WebLog: The many cases of ByRef 中解释了所有这些事情(以及一些更复杂的情况) .

现在，您是说当 setter 超出范围时，应该执行 Don't Copy Back ByRef。但是，这会导致不一致的行为:SomeFunction(sc.SomeProperty)会更新 sc.SomeProperty在 SomeClass 的内部调用时，但同一行代码在 外部 调用时不会静默更新属性(因为 setter 超出范围)。

---

关于你的第一个和第二个问题:

Why was the ByRef templated overload version of the function chosen over the ByVal Object overload version of the function? My guess is that the compiler and IntelliSense simply favor the templated versions over non-templated versions.

他们更喜欢模板化版本而不是需要扩大转换为 Object 的版本. Visual Basic Language Specification 的第 11.8.1 章详细描述了过载解决方案.

Why is Intellisense claiming one thing while the VB compiler is clearly trying something else?

在我看来像是一个错误。