1

Is there a VB.Net equivalent of following C# nameof usage:

[MyAttribute(nameof(MyProperty))]
public class MyClass<T>
{
    private int MyProperty { get; }
}

Note: MyClass is a generic class and MyProperty is private.

I can only work out the following code for non-generic class, with Friend property, otherwise the compiler will complain MyClass.MyProperty is not accessable in this context because it is 'Private':

<MyAttribute(NameOf(MyClass.MyProperty))>
Public Class MyClass
    Private m_MyProperty As Integer
    Friend ReadOnly Property MyProperty As Integer
        Get
            Return m_MyProperty
        End Get
    End Property
End Class
Weifen Luo
  • 603
  • 5
  • 13
  • 2
    This should have nothing to do with CLR. It should be a purely compiler thing. – Weifen Luo Mar 13 '19 at 09:15
  • I use C# all the time :) I'm developing a framework and I do want it works for VB.Net too. – Weifen Luo Mar 13 '19 at 09:18
  • Unfortunately, I can't find an updated VB specification that covers `NameOf` so there's no *formal definition* of how it works and interacts with e.g. scopes. At the end of the day, it's *convenient* but shouldn't be a "requirement" of using your framework, since there's no way for the attribute to work out whether it was passed a `NameOf` obtained value or another string literal. – Damien_The_Unbeliever Mar 13 '19 at 09:19
  • There are two issues here: the scope and generics. I can live with the scope change if I have no choice; but the generics, it just doesn't compile... – Weifen Luo Mar 13 '19 at 09:22
  • 1
    Yes, so its unfortunate that your VB consumers won't be able to benefit from being able to use `NameOf` here. But that won't stop them from being *able* to use your attributes. They just lose out on some compile-time safety. – Damien_The_Unbeliever Mar 13 '19 at 09:31
  • @Damien_The_Unbeliever: you're right, the VB consumers still can use it as ``, to work around both issues. – Weifen Luo Mar 13 '19 at 09:37
  • Actually my framework provides code analyzer to detect such error, so VB consumers would not lose out compile-time safety, they will lose some code refactoring capability though, for example, renaming the property does not update the attribute automatically. Thanks for the reply, I was overly estimated the severity of the issues. – Weifen Luo Mar 13 '19 at 10:31
  • FWIW, this seems like an odd discrepancy between C# and VB.NET. Note that _in general_, C# does the same thing as VB.NET. You can't get the name of an inaccessible member in other context's. It's just that C# treats the attribute as part of the type, and so non-public members are still accessible. Why shouldn't VB.NET do the same? IMHO your goal here is reasonable; have you considered filing a bug against the compiler? Now that everything's on Github, I would expect it should not be hard to do so, and Microsoft has been pretty responsive to issues opened by developers there. – Peter Duniho May 19 '21 at 18:09

1 Answers1

1

VB.NET has a NameOf operator that is supposed to be identical to C#'s nameof operator.

Mike Grove aka Theophilus
  • 1,199
  • 13
  • 23
  • As you can see in the question, the author of the question does know about VB.NET's `NameOf` operator and is trying to use it, but cannot because the VB.NET compiler has different rules about visibility with respect to members referenced by the `NameOf` operator. This post is not in any way an answer to the question; at best, it's a commiseration with the author of the question, agreeing that the operator _"is supposed to be identical"_ but of course is not. – Peter Duniho May 19 '21 at 17:52