You can also view a summary of the video/features as a presentation: <a href="https://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2ffiles.channel9.msdn.com%2fthumbnail%2f6fcbe7ba-1cf1-4332-a9e3-ad559fe907c1.pptx" rel="nofollow">https://view.officeapps.live.com/op/view.aspx?src=http%3a%2f...</a>
Interestingly, if you'd like to check out how some of these features were implemented, you totally can. Roslyn is open-source (<a href="http://roslyn.codeplex.com/" rel="nofollow">http://roslyn.codeplex.com/</a>).<p>That being said, I hope that all the open-sourcing is going to make it available where I really want to use it - Unity, for instance. (Disclaimer: I'm an open source dev @ Microsoft)
Nothing not to love -- a whole bunch of syntax sugar that makes code cleaner without messing around with core concepts that breaks code conceptually. It's also great to see how quickly good ideas permeate the language landscape today versus ten years ago (or maybe it's just good ideas finally permeating the landscape all at once).
I'm going to take some hits for that but... with .NET being open source (never liked Mono..) and all..<p>I'm tempted to use C# in the future again. Using it on Windows has always been good - and now that it compiles to native code too and that the libs are open....
Still hoping they add the !(non-nullable) operator.<p>I know its hard
<a href="http://blog.coverity.com/2013/11/20/c-non-nullable-reference-types/#.VGY_5fnF-QA" rel="nofollow">http://blog.coverity.com/2013/11/20/c-non-nullable-reference...</a><p>But dang I would appreciate it. So much code is cluttered with null checks that increases the robustness of the code at the cost of correctness, readability, and poorly defined behavior.
While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code.<p>As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.
Still no first-class tuple support? Argh! All want is:<p><pre><code> var first, last = parseName(fullName);
</code></pre>
Instead of:<p><pre><code> String last;
var first = parseName(fullName, out last);</code></pre>
Being able to use await in catch and finally must have been incredibly hard to implement for them. Especially in the finally part.<p>I mean - I'm saying this as somebody who hasn't done a lot of C# or .NET work in the last few years, but think about what you would have to do if you had to implement this in a safe and bug-free way.
The null-conditional operators and string interpolation are really cool.<p>I don't use C# anymore (job change, not out of dislike), but I was always really happy working in it. I'm still not a huge fan of Windows, but C# is a wonderful language.
What's new in VB 14 (video): <a href="http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/113" rel="nofollow">http://channel9.msdn.com/Events/Visual-Studio/Connect-event-...</a>
Using static classes as namespaces addresses something I was just complaining about a week ago. Let's take it a step further! Just let us put bare functions in namespaces without the dance of the static class.
I think they missed a trick if the goal was to reduce boilerplate; which I'm all for, I'm very much moving away from C# to F# for this reason (and a few others).<p>Why this:<p><pre><code> public int X { get; }
public int Y { get; } = 5;
</code></pre>
And not this:<p><pre><code> public int X get;
public int Y get = 5;
</code></pre>
The braces serve absolutely no purpose anymore, the semi-colon doesn't serve as a separator between statements. So why leave them?
I'm a tiny bit disappointed with the inclusion of exception filters, but I suppose it is pragmatic feature.<p>I'm fond of a pattern where error codes can be implicitly converted to Exceptions[1].<p>It's often argued that exceptions are for things that your program cannot handle and error codes are for things that it can. But, in my experience, whether or not a bad condition is an error or an exception depends upon the layer in which the code lives.<p>Also, a side benefit of this scheme is that most of the exceptions show up in the class browser, or can be explored through reflection.<p>[1]<a href="https://gist.github.com/noblethrasher/ba37ed6176ebeb679dd2" rel="nofollow">https://gist.github.com/noblethrasher/ba37ed6176ebeb679dd2</a> -- In my example, the error code is an integer, but it could be another class that holds more information about the operation.
These are very nice changes. Especially the ability to write a quick lambda for named functions (or functions which are needed often).<p>The elvis operator is useful to. Makes me think sticking to F# will cause fewer classes of bugs that can happen in C# (the onChanged example is quite interesting).
So these lines are now equivalent:<p><pre><code> public override string ToString() { return String.Format("({0}, {1})", X, Y); }
public override string ToString() => "(\{X}, \{Y})"
</code></pre>
Could it go even further? This isn't paper after all, on screen why shouldn't it look like;<p><pre><code> public override string ToString() => "(X, Y)"
</code></pre>
where the X and Y are either slight italics or underlined or colored to indicate they mean X and Y the variable not X and Y the letters. The IDE would let you just toggle the state between 'variable' and 'literal' with the keyboard.<p>We also get better array initializers:<p><pre><code> public JObject ToJson() {
var r = new JObject();
r["x"] = X;
r["y"] = Y;
return r;
}
</code></pre>
becomes:<p><pre><code> public JObject ToJson() => return new JObject() { ["x"] = X, ["y"] = Y };
</code></pre>
That's cool! Next comes the null-conditional operators:<p><pre><code> public static Point FromJson(JObject json)
{
if (json != null &&
json["x"] != null &&
json["x"].Type == JTokenType.Integer &&
json["y"] != null &&
json["y"].Type == JTokenType.Integer)
{
return new Point((int)json["x"], (int)json["y"]);
}
return null;
}
</code></pre>
Becomes...<p><pre><code> public static Point FromJson(JObject json)
{
if (json?["x"]?.Type == JTokenType.Integer &&
json?["y"]?.Type == JTokenType.Integer)
{
return new Point((int)json["x"], (int)json["y"]);
}
return null;
}
</code></pre>
The check against JTokenType.Integer is just to avoid a casting exception. The null checks are just to avoid null exceptions. I wonder if the compiler could ever handle something like 'this if you can, else null', without actually having any exceptions getting throw and caught underneath:<p><pre><code> public static Point FromJson(JObject json) =>
return new Point((int)json["x"], (int)json["y"]) ?: null;</code></pre>
Because primary constructor was slashed to make a true record type, my new favorite feature is the nameof operator, it is very useful with IPropertyChanged, when you have to use the name of a property to raise a change, it was not type safe if you refactored the name of the property, a workaround used Expression capturing using RaisePropertyChange(p => p.MyProperty) which is very slow (or a CallerMemberName attribute in C# 5 but can be abused), nameof is more elegant.<p>I also love the ?. operator.
They need to add these:<p><a href="https://github.com/MiniProfiler/dotnet/blob/master/StackExchange.Profiling/Helpers/ExtensionMethods.cs" rel="nofollow">https://github.com/MiniProfiler/dotnet/blob/master/StackExch...</a><p>They're extremely useful and intuitive string helper methods. Truncate(), IsNullOrWhiteSpace(), etc are things I use daily. And while you can type string.IsNullOrWhiteSpace(string) that is annoying and counter-intuitive.
I did a talk a few months back going over the changes up until today, and what is coming in C# 6, this was before they decided to drop primary constructors.<p><a href="https://www.youtube.com/watch?v=BA3sL783_Co" rel="nofollow">https://www.youtube.com/watch?v=BA3sL783_Co</a>
It all looks really promising. Love it.<p>I'm a little worried about "nameof" in the hand of amateur programmers though. Efficiency aside (because it's not efficient), code readability might take a hit.
I love the new read-only auto properties. 90% of the objects I write are immutable and it's a pain to declare all those private readonly backing fields just to return them in getters.
Lots of little things but they're pretty handy. I wish I still wrote in C#; perhaps that day will come when they start distributing the .Net runtime on Linux / Mac OS X.
await in catch and finally is going to be great! I'm an amateur c# programmer, but I hated having to set flags that get called later to do async methods with try/catch.