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

C#

1

varx=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.

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.

22 Comments

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.

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.

“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.

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?

@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?

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?
KISS

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.

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:

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.