Found a text reference: <a href="https://www.infoq.com/news/2017/08/CSharp-8" rel="nofollow">https://www.infoq.com/news/2017/08/CSharp-8</a>
Very excited about the Nullable Reference Types.<p>Besides that, the feature I want most in C# is enum exhaustion checking. So I can write:<p><pre><code> enum Color { red, green, blue };
public static string SuperheroFromColor(Color c)
{
if (c == Color.red)
{
return "Superman";
}
else if (c == Color.green)
{
return "Green Lantern";
}
else if (c == Color.blue)
{
return "Spiderman";
}
}
</code></pre>
and not get a compiler error (that not all code paths return a value). But if I added "yellow" as an enum option, then I would get a compiler error. I realize that Color can be cast from an out-of-range int, so it's a little complicated. I'm willing to put something extra after the last else:<p><pre><code> unreachable return null;
</code></pre>
or use a special switch statement. I just want something so the compiler checks that I have accounted for all normal enum values.<p>Is anyone talking about such a feature, or where would I request it? Can I write it myself as a Roslyn extension?
This looks great. I just stepped back into java for a one off project, after not touching it for about 15 years. I was surprised how antiquated it felt compared to modern C#. Glad to see Microsoft is not letting the language languish.
I'll crank up those `null` assignments to non-optional references warnings up to compiler errors. There's really no reason to ship software that doesn't explicitly declare something as nullable.<p>The `!`'s are always code smells. I hope I can turn them into warnings or build errors.
Great to see these Swift features[1] appearing in C#:<p>* Nullable Reference Types
This makes it so much easier to reason about references. I always found it strange that C# had nullability on value types, but not on reference types.<p>* Default Interface Implementations
Inherit an interface, and get an implementation "for free". This makes for a very powerful way to define interfaces and default implementations.<p>* Extension Everything
As noted in the video/text, the current syntax feels a bit weird -- having to use a static class.<p>[1]: Not saying these are exclusive to Swift, or Swift was the first to implement them.
Interesting, the new type IAsyncEnumerable is like an Observable. But it's pull instead of push. Ie it supports backpressure like the Reactive Streams [1] standard in the JVM world.
I seem to recall that Erik Meijer had some strong opinions when that standard was forming on backpressure and anything that's not purely push based.<p>Personally as a developer I really like having the choice whether to buffer in one place in my system (using a persistent queue f.i.) and have the rest of the system cooperate in tandem without running out of memory f.i. Or to choose to ignore elements when stuff is just going to fast. Etc.
I feel more in control of the behaviour under load of my system.<p>I guess Lightbend was onto something when they took the old EAI notion of backpressure (as f.i. described in Gregor Hohpes book) and implemented it in stream processing and started an interoperability standard around it.<p>[1] <a href="http://www.reactive-streams.org/" rel="nofollow">http://www.reactive-streams.org/</a>
I feel like I've been waiting for non-nullable reference types for forever.<p>What they talk about here, with explicit nullable reference types is so close but stumbles at the last hurdle. Having some kind of opt in on the compiler that makes regular references non-nullable is great for new projects (and arguably the best thing for the language itself), but leaves all legacy code out in the dark. You can't switch on a compiler option like this on any big existing project without massive effort. (And massive effort means management approval and planning and justification)<p>They got the case by case opt on the wrong part of the feature. It's really the non-nullability of a reference that's most important to be able to be opted in to on a case by case basis. (And case by case opt in means low effort, so it doesn't need big up front approval or planning, you just get on and write better code with fewer bugs.)<p>What's really needed is something like this<p><pre><code> String! s = null;
</code></pre>
Where the ! makes the s reference non-nullable, so any attempt to assign null (or anything that could be null) to it is a compiler error.<p>And it's so disappointing because he comes so so close to that at the end with his talk of s!. as a way to say that you know something is not null, but it just doesnt quite get the benefit right.<p>It's non-nullability of reference types that should be the central feature here.<p>I'm just really hoping that these guys know what they are doing, and it's just he couldn't explain the subtleties in a short video, and this is going to turn out working the right way in the end.
Why is default interface implementation controversial? I get it for moving existing .Net functionality around but for development of new code, what's the downside.<p>Coming from C++ it seemed like C# interfaces (and Java at the time) felt like a punishment. Now I'm sort of used to them.
There's some interesting and controversial stuff in here. I am very excited about extension everything. I also like the new extension method syntax; much cleaner and a much clearer expression of intent.