C# Blooper №14: Weird / annoying interface method visibility rules.

Before reading any further, please read the disclaimer.

As it turns out, an explicit interface method implementation in C# must be tied to the base-most interface to which it belongs; it cannot be tied to a descendant interface.

namespace Test14
{
    class Test
    {
        interface A
        {
            void F();
        }

        interface B: A
        {
        }

        class C: B
        {
            void A.F() //OK
            {
            }

            void B.F() //error CS0539: 'B.F' in explicit interface declaration is not a member of interface
            {
            }
        }
    }
}

Well, sorry, but... it is.

-

C# Blooper №13: Stack and Queue do not implement ICollection

Before reading any further, please read the disclaimer.

This is a blooper of the Common Language Runtime (CLR), not of the language itself: Stack<T> and Queue<T> derive from ICollection, but not from ICollection<T>, so they do not support the Remove( T ) method! Why, oh why?

-

C# Blooper №12: 'Where' constraints not included in method signatures

Before reading any further, please read the disclaimer.

When writing generic methods in C#, it is possible to use the 'where' keyword to specify constraints to the types that the generic parameters can take. Unfortunately, these constraints cannot be used for resolving overloaded methods. Case in point:

namespace Test12
{
    class Test
    {
        public static bool Equals<T>( T a, T b ) where T: class
        {
            return object.Equals( a, b );
        }

        public static bool Equals<T>( T a, T b ) where T: struct //error CS0111: Type 'Test' already defines a member called 'Equals' with the same parameter types
        {
            return a.Equals( b );
        }
    }
}

-

C# Blooper №11: Zero to Enum conversion weirdness

Before reading any further, please read the disclaimer.

When you assign an enum to int, you have to cast it. That's good. When you assign an int to enum, you also have to cast it. That's also good. But if you assign zero to an enum, you don't have to cast it! Go figure.

namespace Test11
{
    class Test
    {
        public enum myenum
        {
            a, b, c
        }

        void test_myenum( myenum f, int i )
        {
            i = (int)myenum.a; //need to cast; that's good.
            f = (myenum)5; //need to cast; that's still good.
            f = 0; //wtf? no need to cast?
        }
    }
}

-

C# Blooper №10: Switch statements are not properly formatted.

Before reading any further, please read the disclaimer.

This is rather a Microsoft Visual Studio blooper than a Microsoft C# blooper: When formatting source code, Visual Studio offers an "indent case contents" option, but you will only find it useful if you happen to have a crooked notion as to how switch statements should be formatted. The one and only normal form of formatting switch statements is not supported.

namespace Test10
{
    class Test
    {
        void statement() { }

        void test( int a )
        {
            /* with "indent case contents" option selected: */
            switch( a )
            {
                case 42:
                    /* this is not properly indented */
                    {
                        statement();
                        break;
                    }
                default:
                    /* this is properly indented */
                    statement();
                    break;
            }

            /* with "indent case contents" option deselected: */
            switch( a )
            {
                case 42:
                /* this is properly indented */
                {
                    statement();
                    break;
                }
                default:
                /* this is not properly indented */
                statement();
                break;
            }

            /* the normal way of indenting cannot be achieved: */
            switch( a )
            {
                case 42:
                {
                    statement();
                    break;
                }
                default:
                    statement();
                    break;
            }
        }
    }
}

I know, you might disagree that my way of formatting switch statements is in any way 'normal'. So, in your case, let us agree on this: my way of formatting switch statements, whether you like it or not, is in perfect accordance to the way I format the rest of my code; and since Visual Studio allows me to precisely describe my coding style, it should also allow for a switch statement style that matches the rest of my code.

-

C# Blooper №9: Annoying case statement fall-through rules.

Before reading any further, please read the disclaimer.

Overall, C# takes an approach which is far more friendly to novice programmers than its predecessors, C and C++ were. For example, in the case of switch statements, C# does not allow the old, error-prone style of C and C++ where you could simply fall through from one case statement to the following one; instead, at the end of each case statement C# requires either a break statement, or a goto statement to explicitly jump to another label. That's all very nice and dandy, except for one thing: C# requires a break or goto even at the last case statement of a switch statement!

namespace Test9
{
    class Test
    {
        void statement() { }

        void wtf_is_it_with_falling_through_the_last_case_label( int a )
        {
            switch( a )
            {
                case 42:
                    statement();
                    break;
                default:
                    statement();
                    break; //Need this 'break' or else: CS0163: Control cannot fall through from one case label ('default:') to another
            }
        }
    }
}

I mean, seriously, WTF?

-

C# Blooper №8: No warnings for conditions that are always true/false

Before reading any further, please read the disclaimer.

The Microsoft C# compiler does not issue 'condition is always true' and 'condition is always false' warnings. Perhaps these warnings are not particularly meaningful in Java, which lacks conditional compilation directives, and therefore if( true ) and if( false ) are the only means of achieving conditional compilation; but in C#, which has special conditional compilation directives, conditions which are always true or always false are invariably so by mistake; therefore, these warnings would indeed be meaningful, and useful.

namespace Test8
{
    class Test
    {
        void statement() { }

        void test()
        {
            if( true ) //no warning about 'condition is always true'.
                statement();

            while( false ) //no warning about 'condition is always false', even though the compiler obviously knows what's going on, since the following warning is issued:
                statement(); //warning CS0162: Unreachable code detected 
        }
    } 
}

For more information see Why the Microsoft C# compiler lacks many useful warnings.

-