News on the future of C# as a language

What’s going on here?

Mads Torgersen have commented on two language feature suggestions on uservoice. Noting that they are actively working on them.

If you have not voted for your most wanted features yet, you should head over to uservoice right now and vote away (unless you want to get VB 6.0 back, in which case… shoo).

Old news!

Sure, this is not exactly news, these little nuggets were already unveiled at NDC London. But still, having Microsoft commenting on the features on uservoice is still a neat milestone of sorts.

What language features are we talking about then?

?. operator

This is a thing of beauty if you ask me. Usage is simple enough, if you write

var x= foo?.bar?.baz();

and foo or bar is null, x will be null. In other words you will always get a nullable value from this chain. This makes it simple to assign your own default value by simply appending “?? y” to the line instead of trying to figure out if that zero you got back were a default value or the real value.

One slight issue with the current suggestion is that it will only work if the compiler knows if you have a nullable type or not. So the json parsing code will not be better with the current suggestion since your dynamic variable kind of removes that knowledge from the compiler.

Prototyping in the next few months is what Mads Torgersen said in his response for the uservoice suggestion.

Default value on properties

No more adding a backing field/setting a value in the constructor just to make sure that your property has the correct default value. Now we will be able to set the value on the property row instead.

public int X { get; set; } = x;

Yup, looks simple enough! Also we will be able to write:

public int Y { get; } = y;

This ought to be the same as

public int Y { get { return y; } }

The reduction in the number of characters is always nice, but personally I don’t care that much about that particular case.

Time for speculation!

Ah yes, what does this mean? Is Roslyn imminent? Will we know at Build?

Personally I think that we will see these features at the same time as Roslyn gets released. But then again there are information saying that Roslyn might not make it into the next version of Visual Studio. I suppose we will know soon enough.

This Post Has 22 Comments

  1. public int Y { get { return y; } }

    What will be returned? As written, it is the value of some variable y, but

    public int X { get; set; } = x;

    suggests it should returned the value of an internal valuable that was initially assigned the value of y.

    If so, when it is assigned? Before the constructors run, after the constructor runs, after the parent constructor runs?

    Does it work with default getters and setters only? If no, how do I distinguish between calling the setter and assignment to a private variable? If I cannot, the problem is not solved while confusion is added.

    It is either poorly explained or catering to User who knows nothing but her way of doing (simple) things.

    1. As far as I gather, writing

      public int X { get; set; } = 10;

      results in the same code as writing

      private int x=10;
      public int X{ get{ return x; } set{ x=value; } }

      From Mads uservoice comment: “The initializer directly initializes the underlying field – it doesn’t go through the setter. For that reason, it is now meaningful to allow getter-only auto-properties:”

    2. Andrey, the new syntax doesn’t add any new ambiguity that doesn’t already exist. You can already write this declaration:

      public int X = x;

      We know that “X” will not change when “x” does, because we know that default values are only evaluated once.

      By adding a property, the rules don’t change. The meaning of “= x” is still a default value assignment that is evaluated once.

  2. I think they should open up the C# preprocessor to programmers, as it is in C++. C# pretends not to have a preprocessor, but that is rubbish. Consider the ‘event’ keyword, for example. It is possible to write by hand everything it generates; it’s basically just a preprocessor command. In C#, because the designers like to pretend it doesn’t preprocess, we are stuck with the hopelessly restrictive [Conditional] way of switching code in and out of different software versions. In C++, you could create a single header file that got included in all others, to control versions and other stuff. E.g.

    #if defined(DEBUG) && defined(PC)
    #define RUN_IN_WINDOW
    #define RUN_FULL_SCREEN

    I miss control like this. And the thing is that C# has it all; it is just hidden from developers, to try to maintain the pretence that C# is modern and doesn’t need an old-fashioned precompiler.

    Rant over.

    1. Yes a very good idea… Bring back all the stupid “look arround in a 1mill lines code base to find your “control it all file” through a chain of #includes. You also want makros back I’d guess?
      Have a look at:

      “Although the compiler does not have a separate preprocessor, the directives described in this section are processed as if there were one. They are used to help in conditional compilation. Unlike C and C++ directives, you cannot use these directives to create macros.”

      I didn’t have any problems to create conditional compilation configurations, just set your symbol on project level?
      I agree that you are not that flexible with c# “preprocessing” if you have been in C++, but with that all the “bad” things you could do (by mistake?) are also gone.

  3. openly write what you have. why u r hiding shit..

    public int x=10;
    public int X{ get{ return x; } set{ x=value; } }

    I could come up with lang where it will shorten everything.

    x {}=>means
    int main() {
    //your code

    return 0;

  4. VB6 rules.

  5. Every thing Good for you! As compiler design’s thought they may want to initialize or declare public type variable with value for design time?. After some process get over then it may get or set dynamically at runtime for the same by setting or getting those property of values?

    1. The public part of the field were merely a typo. It should have been private as you might have thought.

  6. @Patrick Skelton: Whether it’s preprocessed under the hood or not, it shouldn’t matter to the author. They use the keyword because they want a certain behaviour. That behaviour shouldn’t change between projects or sourcefiles.

    @cuz: And how many times do you need to do that? Does that syntactic change make your code easier to read, or same you a lot of time writing boilerplate code?

  7. This is stupid. Is there any reason to do this? No. Is there reason not to, yes, it is confusing and hinders maintainability.
    I do not believe these folks maintain code. They may write it, but they do not maintain it. Code should read like a book.
    I have heard the argument that it saves key strokes. Well, the Dragon Writer can type far faster than you can, but it cannot tell a story. Keystrokes are not the limit on productivity.

    I have written and maintained code from since the PC was invented. Code Maintenance is a major cost of any project. I do not believe that these folks maintain code. The problem is that Microsoft sells a product. They need to keep updating it to have something to sell. Unfortunately, what can you do to improve a well designed tool. There are limits to how many useful improvements you can make to a good tool. Mostly you just add useless or bad features. I am a .Net developer, but I can do most of the same thing with the much simpler Python (maybe all, I’m not an expert at it) Why does .Net need so much weird stuff to do what Python can do with simple tools that look like .Net tools without the … weird additions?

    1. I have to agree with Mike on this. Absolutely not necessary. You are just adding one more dimension of syntax complications to the language. C# today is one of the best languages simply because of its consistency and simplicity in syntax. Please do not ruin this to save keystrokes. Readability is paramount.

      BTW, does anyone have a list of Microsoft products developed with C#?

      1. I don’t like the properties initialization thing. But this code, var x= foo?.bar?.baz(); looks like poetry to me. It ain’t hiding anything and is much more concise than doing manual checking.

    2. Mike, how does it hinder readability?

      The ?. operator:

      If . is readable, how does adding one character suddenly make it unreadable? This is simply the syntax equivalent of the “X” and “TryX” methods (where the “Try”-prefixed version returns null instead of raising an exception), and the ? character already has meaning in the language as “maybe”.

      Default values:

      We already have this syntax.

      The following code says “Y is a field with a default value”:

      public int Y = y;

      And this code says “Y is a property”:

      public int Y { get; }

      Combining the existing syntax to say “Y is a property with a default value” is completely natural. In fact, I was surprised that I COULDN’T do this in the first place when I learned this syntax.

      You say this will make code difficult to maintain. Give examples. In what situation would this:

      if (a != null || a.b != null) {
      return null;
      return a.b.c;

      be more maintainable than this:

      return a?.b?.c;

      Or this:

      private int _y = 1;
      public int Y {
      get { return _y; }
      set { _y = value; }

      be more maintainable than this:

      public int Y { get; set; } = 1;

      In both cases, the new syntax results in less code duplication: a plus for maintainability.

      1. Sorry, that should be:

        if (a == null || a.b == null)

        (See? Even sample code requires more maintenance than the new operator!)

  8. C# should be clean.
    Those who want messy symbols, etc, go to C++.

    C# should get the best of C++ and Avoid the mess of C++

  9. I like C++ and I liked C before it, and over the years I have come to really enjoy working with C#. But, there are times when the language limits you. Not out of some misguided form of protection, but simply due to its roots. When new features are considered to expand the language, these are opportunities to remove some of these limits. I like to think that the committee providing oversight into the language as it evolves will maintain the strengths of managed code and the useful protections it provides through clean design.

    That being said, I find it humorous to read some of the negative comments here spouting against the 2 proposed features covered in the article. C# already has syntax to allow you to declare an int? or a bool? that can be null along with the normal values. This is useful at times when you need to establish a state that is not yet set and then allow the full range of normal values for the member to be used in the class for other class specific information. To extend that syntax a bit to allow for checking of an object to be null within an attempted reference instead of having to wrap the example given within 2 “if” conditions (even combined by an “&&” on one if is still 2 conditions to test)is actually very concise and serves a similar purpose to the already present feature carried over from C / C++ of the inline if syntax of (condition) ? true value : false value. This too allows concise code without added lines cluttering the flow.

    I suppose the same negative logic could be applied to lambda expressions as they certainly are not easy to follow for the novice and even those who love them often admit that getting one just right takes a fair bit of doing and coming back to one after some time away requires additional study to fully grasp what it is doing.

    There are often tradeoffs in code and in coding styles and like flavors of ice-cream, each to their own. Just because one person does not care for it or choose to use it does not make a feature inherently bad… Seriously, open your mind a bit, hey… Change is inevitable.


  10. On the default value on properties:
    public int X { get; set; } = x;

    When X is set, is the underlying integer x set too, or would this act like the current public int X { get; set; } with the instantiation process executing X = x; ?

    It’s implied that the first is true from what is said about the “get” alone.

  11. 1. I see the ?. operator as a “nice-to-have” thing~

    2. Default value properties are an UGLY MESS

    3. There are things existing in C++ more important to integrate in C# , like const methods, reference to const variables and reference to const parameters.

  12. I like the initializer doding

    public int X { get; set; } = 10;

    As it would make source shorter, especially in mvvm scenario’s.

    The alternatieve :
    public int { get; set; default 10; }
    looks even netter.

    1. I agree… neater

  13. This is NOT stupid.

    Currently the {GET;SET;} is simple enough. It does not need to be tinkered with;

    Perhaps “=x” should simply be “=const(x)” to display a default and not be concerned with maintaining and internal “x” variable?

Leave a Reply

Close Menu