Search
Close this search box.

Poor, confused C# compiler

The C# compiler is a pretty good thing, but it has limitations. One limitation that has given me a headache this evening is its inability to guard against cycles in structs.  As I learn to think and programme in a more functional style, I find that I am beginning to rely more and more on structs to pass data.  This is natural when programming in the functional style, but structs can be damned awkward blighters.

Here is a classic gotcha.  The following code won’t compile, and in this case, the compiler does its job and tells you why with a nice CS0523 error:

    struct Struct1
    {
        public Struct2 AStruct2
    }

    struct Struct2
    {
        public Struct1 AStruct1
    }

Structs are value types and are automatically instantiated and initialized as stack objects.  If this code were compiled and run, Struct1 would be initialised with a Struct2 which would be initialised with a Struct1 which would be initialised with a Struct2, etc., etc.  We would blow the stack.

Well, actually, if the compiler didn’t capture this error, we wouldn’t get a stack overflow because at runtime the type loader would spot the problem and refuse to load the types.  I know this because the compiler does a really rather poor job of spotting cycles.

Consider the following.  You can use auto-properties, in which case the compiler generates backing fields in the background.  This does nothing to eliminate the problem.  However, it does hide the cycle from the compiler.  The following code will therefore compile!

    struct Struct1
    {
        public Struct2 AStruct2 { get; set; }
    }

    struct Struct2
    {
        public Struct1 AStruct1 { get; set; }
    }

At run-time it will blow up in your face with a ‘Could not load type <T> from assembly’ (80131522) error.  Very unpleasent.

ReSharper helps a little.  It can spot the issue with the auto-property code and highlight it, but the code still compiles.  However, ReSharper quickly runs out of steam, as well.   Here is a daft attempt to avoid the cycle using a nullable type:

    struct Struct1
    {
        public Struct2? Struct2 { get; set; }
    }

    struct Struct2
    {
        public Struct1 Struct1 { get; set; }
    }

Of course, this won’t work (duh – so why did I try?).  System.Nullable<T> is, itself, a struct, so it does not solve the problem at all.  We have simply wrapped one struct in another.  However, the C# compiler can’t see the problem, and neither can ReSharper.  The code will compile just fine.  At run-time it will again fail.

If you define generic members on your structs things can easily go awry.  I have a complex example of this, but it would take a lot of explaining as to why I wrote the code the way I did (believe me, I had reason to), so I’ll leave it there.

By and large, I get on well with the C# compiler.  However, this is one area where there is clear room for improvement.

Update

Here’s one way to solve the problem using a manually-implemented property:

    struct Struct1
    {
        private readonly Func<Struct2> aStruct2Func;

        public Struct1(Struct2 struct2)
        {
            this.aStruct2Func = () => struct2;
        }

        // Let's make this struct immutable!  It's good practice to do so
        // with structs, especially when writing code in the functional style.
        // NB., the private backing field is declared readonly, and we need a
        // constructor to initialize the struct field.  There are more optimal
        // approaches we could use, but this will perform OK in most cases,
        // and is quite elegant.
        public Struct2 AStruct2
        {
            get
            {
                return this.aStruct2Func();
            }
        }
    }

    struct Struct2
    {
        public Struct1 AStruct1 { get; set; }
    }
This article is part of the GWB Archives. Original Author: cnayoung

Related Posts