Question

I’m wondering if any other C# developers would find it an improvement to have a compiler directive for csc.exe to make whitespace significant a la Haskell or Python where the kinds of whitespace create code blocks.

While this would certainly be a massive departure from C-style languages, it seems to me that since C# is ultimately being compiled down to CIL (which would still have the curly braces and semicolons), it really is just a parsing trick the compiler can handle either way (that is, it can either deal with significant whitespaces or not). Since curlies and semicolons are often a barrier to entry to C# & they are really only parsing helpers (they don’t in themselves impart meaning to your code), they could be removed a la Haskell/Python.

F# handles this with the #light compiler directive which you can read about in Lightweight syntax option in F# 1.1.12.3.

I’d like to see the same thing in C#: a #SigSpace or somesuch directive that would direct csc.exe to treat the source like a Haskell file in terms of whitespace (just as an example).

Standard C#:

public void WhiteSpaceSig()
{
    List<string> names = new List<string>();
    List<string> colors = new List<string>();

    foreach (string name in names)
    {
        foreach (string color in colors)
        {
            // bla bla bla
        }
    }
}

Significant whitespace:

#SigSpace

    public void WhiteSpaceSig()

        List<string> names = new List<string>()
        List<string> colors = new List<string>()

        foreach (string name in names)
            foreach (string color in colors)
                // bla bla bla

I’m not saying that I want this in C#, but I am interested in what the tradeoffs are. My guess is that most C# developers have gotten so used to the syntax that they won’t be able to see how artificial it is (though it may in the end make the code easier to read).

Answer 1

You might be interested in Kirill Osenkov’s thesis, Designing, implementing and integrating
a structured C# code editor.

The underlying idea is that while the braces are part of the C# language as defined, your editor doesn’t have to show them to you. Osenkov implemented an editor control for SharpDevelop that represents brace pairs as indentation, and makes it faster for the programmer to work with the structure of the code. Jump to page 113 in the linked document to see a good example.