Accessibility of protected members of attribute classes

[abelbraaksma]

From the current spec, sections on accessibility and attributes do not mention how protected members of an attribute and protected attributes are scoped w.r.t. attribute usages.

Furthermore, it is unclear or at least under-specified, whether protected members of classes are accessible from within an attribute declaration of an inheriting class. In fact, the spec appears to prohibit such use as it talks about program text of a type:

and the program text of a type is defined as all program text contained in the type_declarations of that type (including, possibly, types that are nested within the type

Here, type_declarations are within the type and do not include the class declaration itself, afaik.

Example #​1

This example is taken from this discussion: dotnet/fsharp#3172.

public class TestClassBase
{
  protected const string Foo = "Bar";
}

The following is valid as per the status quo, but appears to be invalid per the spec:

// protected const is accessible, though spec appears to disallow it
[Trait(Foo, "")]
public class MyCSharpTestClass : TestClassBase
{
}

Example #​2

public class MyAttribute: Attribute
{
    protected const int TestField = 42;
    protected MyAttribute(int x)
    {

    }
}

The following is valid, though again the spec appears to prohibit this, in particular by this statement in the spec:

If C does not have public accessibility, then a compile-time error occurs.

// protected ctor does not throw error, but spec disallows this
// and: protected const is accessible outside its scope
[My(MyAttribute.TestField)]
public class OtherAttribute: MyAttribute
{
    public OtherAttribute(int x): base(x) { }
}

Example #​3

If I add a protected int TestProp; then suddenly the rules of the spec seem to apply properly and indeed, it is not accessible. Which suggests that the protected constant above has crept in the status quo, but does not align with the spec. This rule is actually in the spec:

Let Name be the identifier of the named_argument Arg. If Name does not identify a non-static public read-write field or property on O, then an exception is thrown.

(the spec has this as a runtime error, which is somewhat surprising...)

---

I do not propose to suddenly start prohibiting this, but I do think we can do better in the section an accessibility to include whether or not the attribute declaration of a type or member are part of the program text of the type or not, and in the section on attributes, what we mean by public, as clearly attributes can be used when they are protected as well.

[333fred]

It's very likely that the rules the C# compiler implements here do not match the spec exactly, due do the native compiler's behavior. Name lookup especially was a place where the native compiler often played a bit loose with the rules, and in these cases we often matched Roslyn's behavior to the native compiler in order to allow people to move forward. I do agree that a reading of the spec suggests these cases should be illegal, but that's the likely reason for the behavior.

[abelbraaksma]

Thanks @333fred. I do think, though, that we ought to say something in the spec by clarifying the extend to where "program text" applies. Likewise for the unclear distinction between runtime and compile time errors of the attribute constructor (when not public).

Or we could change it such that the "playing loose" rules of the C# compiler become the de jure rules.

[abelbraaksma]

Time to close this :)