Suspected Bug

[The-Futurist]

I was refactoring code earlier and introduced an enum as opposed to using an integer representation. Oddly the compiler rightly complains about integers being used, but specifically does not care if zero is used:

Here's sample code that repros the issue:

namespace ConsoleApp5
{
    internal class Program
    {
        static void Main(string[] args)
        {
            var temp_1 = GetValue(0);
            var temp_2 = GetValue(1);
        }

        public static int GetValue(GpioPort X)
        {
            return (int)(X);
        }
    }

    public enum GpioPort
    {
        GpioA,
        GpioB,
        GpioC,
        GpioD,
        GpioE,
        GpioF,
        GpioG,
        GpioH,
        GpioI,
        GpioJ,
    }
}

It will even accept zero if the enum definition itself has no zero valued member, like if we start the numbering at say, 1. Look at this variant of the above example:

namespace ConsoleApp5
{
    internal class Program
    {
        static void Main(string[] args)
        {
            var temp_1 = GetValue(0);
        }

        public static GpioPort GetValue(GpioPort X)
        {
            return X;
        }
    }

    public enum GpioPort
    {
        GpioA = 1,
        GpioB,
        GpioC,
        GpioD,
        GpioE,
        GpioF,
        GpioG,
        GpioH,
        GpioI,
        GpioJ,
    }
}

[huoyaoyuan]

It's a known compiler deviation from standard:
https://github.com/dotnet/roslyn/blob/main/docs/compilers/CSharp/Deviations%20from%20Standard.md#implicit-enum-conversions-from-zero

I believe it's for bug-to-bug compatibility.

Issues about compiler behavior goes to roslyn repo.

[The-Futurist]

OK but this is not a deviation from that standard, the standard says:

...any integer type and the value zero to be converted to any enum_type and to any nullable_value_type whose underlying type is an enum_type.

That last example is allowing conversion from zero to an illegal enum value, no member has the value zero. That returned value temp_1 could be passed around and the problem could propagate and cause all kinds of issues surely? In my case I introduced the enum specifically to restrict the allowed values so that an illegal index cannot be used, but as you can see, it can.

Maybe someone from MS can move this to the Roslyn repo?

[CyrusNajmabadi]

That last example is allowing conversion from zero to an illegal enum value,

0 is always a legal enum value. The default-sequence-of-bits (like null, 0, false, default(Struct)) is legal for all types in .Net and C#.

no member has the value zero.

Enum values have no requirement that they must correspond to a particular enum member.

Enums span the entire integral range of their base type. The named members are simply a subset of those that are chosen to have special names. The rest of the values are legal (and programs should be written to expect that tehy may run into them). This is especially true for 0 which is the default state of any enum.

[CyrusNajmabadi]

That returned value temp_1 could be passed around and the problem could propagate and cause all kinds of issues surely?

Code that processes enums should be written to handle any value from the enum's base integral range. You can choose what the best way of handling things is for your domain. That could be anything from mapping unnamed-values to named ones, or throwing when you get values you do not accept.

so that an illegal index cannot be used,

An 'illegal index' is something your particular domain has determined is part of your enum values. Neither the language or runtime has such a concept. If you want to restrict such things though, you can absolutely do so by writing an analyzer to help out here.

Maybe someone from MS can move this to the Roslyn repo?

Roslyn is behaving as expected and as documented. The language group and compiler are in agreement on the behavior of enums in general, and on this specific, documented, legacy carve-out for the value 0.

[The-Futurist]

(and programs should be written to expect that they may run into them). This is especially true for 0 which is the default state of any enum.

Am I to take it then that you are recommending that every public interface that can receive enum valued arguments, should do an argument validity check on the underlying integer value? Such a check should always test for zero at the very least, but perhaps also check that any non-zero value also corresponds to a defined enum member value?

Do Microsoft do this within their own codebase?

[CyrusNajmabadi]

should do an argument validity check on the underlying integer value?

Yes. We also have varying docs and guidelines on these topics. Including analyzers (for example: https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1008).

Do Microsoft do this within their own codebase?

Yes.

[CyrusNajmabadi]

Closing out as by design. The compiler, for legacy purposes, has always allowed the constant value 0 for any place an enum is used.

[The-Futurist]

Even if the value zero has no corresponding enum member? seriously?

[The-Futurist]

Oh, I see you closed it, you don't want a discussion about it, very well as you wish.

[huoyaoyuan]

Yes, since 0 can always be produced with default(T) or new arrays.

[CyrusNajmabadi]

Even if the value zero has no

The value 0 is legal for all enums. :)

[CyrusNajmabadi]

Oh, I see you closed it, you don't want a discussion about it, very well as you wish.

You're welcome to discuss it. This was just closed out as it is not a bug. It's the system working very much as documented.

[TahirAhmadov]

#3179