Invalid example in "Using static directives"

[RexJaeschke]

In this section, we have the following narrative and example:,

A using_static_directive only imports members and types declared directly in the given type, not members and types declared in base classes.

Example:

namespace N1 
{
    static class A 
    {
        public static void M(string s){}
    }

    static class B : A        // *** THE PROBLEM STARTS HERE ***
    {
        public static void M2(string s){}
    }
}

namespace N2
{
    using static N1.B;

    class C
    {
        void N()
        {
            M2("B");      // OK, calls B.M2
            M("C");       // Error. M unknown 
        }
    }
}

the using_static_directive imports the method M2 contained in N1.B, but does not import the method M contained in N1.A. Thus, the reference to M in the body of C.N results in a compile-time error because no members named M are in scope. Developers must add a second using static directive to specify that the methods in N1.A should also be imported.

end example

The intent is there be only 1 compilation error, on the method call M("C"), as noted in the accompanying comment. However, there is another error, which prohibits the example from demonstrating its point. That error occurs on the line

static class B : A

In 14.2.2.4.1 General, we have

A static class declaration is subject to the following restrictions:

• ...
• A static class shall not include a class_base specification (§14.2.4) and cannot explicitly specify a base class or a list of implemented interfaces. A static class implicitly inherits from type object.

So, we must remove A as a base class. That leaves the implicit base System.Object. So, what member from that type can we try to access, and fail, as the example is intended to demonstrate? I tried ReferenceEquals among other members, but anything I put inside method N is inside class C which is also derived implicitly from System.Object, and does allow me access to that base's members.

I have not come up with a resolution.

[KalleOlaviNiemitalo]

Could resolve by making the classes A and B not static.

namespace N1 
{
    class A 
    {
        public static void M(string s){}
    }

    class B : A
    {
        public static void M2(string s){}
    }
}

namespace N2
{
    using static N1.B;

    class C
    {
        void N()
        {
            M2("B");      // OK, calls B.M2
            M("C");       // Error. M unknown 
        }
    }
}

SharpLab

[RexJaeschke]

@KalleOlaviNiemitalo Yes, that solves it; thanks!

[KalleOlaviNiemitalo]

Do you intend to publish any corrigenda via ECMA?

(I thought examples were informative rather than normative, but §5 Conformance does not say so, and Guidelines to Spec Writing and Formatting mentions "Examples and Notes marked as such are informative".)

[RexJaeschke]

@KalleOlaviNiemitalo Unlike ISO's Technical Corrigendum [TC], Ecma has no formal mechanism to publish errata, although any Ecma committee could make errata available informally in some public place. The C# committee has never done that. Having produced TCs myself for other (ISO-related) standards committees, it can be a lot of work. Note that our current plan is to produce a new revision of the whole spec every 12 months.

Yes, examples and notes are informative although §5 Conformance doesn't say so (and it probably should), but §4 General description does.

[KalleOlaviNiemitalo]

I imagine the committee could just fix the errors on the branches, on top of the tags.

• V5-standard...standard-v5
• V6-standard...standard-v6

I don't know whether any current sponsors would want to spend resources on that, though.

[RexJaeschke]

Up to now, once each Ecma spec has been approved by Ecma, it has been Fast-Tracked to ISO/IEC JTC 1, and adopted as an ISO spec as well. Changing anything on the Ecma site would not get applied to the ISO version, and we don't want the published versions to differ.

[KalleOlaviNiemitalo]

Unlike ISO's Technical Corrigendum [TC], Ecma has no formal mechanism to publish errata

Clause 9.5 of Ecma By-laws (June 2022) describes the publication of a Corrigendum "when a Standard or a Technical Report contains errors which makes it unusable as published". Does "errata" specifically mean errors that do not have that effect?

[RexJaeschke]

@KalleOlaviNiemitalo I just found last week that Ecma does have the ability to publish a Corrigendum, but this has very rarely been used. When I mentioned "errata," I was thinking about how one might make available to the public important corrections that are not in the latest adopted standard. However, maintaining an errata list separate from a merged PR against the current draft that has those changes means extra work, and, frankly, we don't have the resources within TG2 for that.