Guys, explicit interface implementations are not private. Please try to explain it another way. Calling it private creates confusion. The method is not accessible from an instance of the class but this does not make it private. Private access modifier is responsible for encapsulation, protecting invariants and all that jazz. Explicit interface implementation serves to allow two methods with the same name in different interfaces to be implemented separately and also to avoid API pollution with methods that are not needed or named inappropriately (think of Close vs Dispose on some classes where both methods do the same thing)
I don't understand why people always focus on generating the database or generating the model with EF. There is certainly one more way to use EF and in my experience it is the most robust one and results in least amount of headaches - create your database and write your model by fact.
This is the kind of talks Anders (Hallowed be His name) should be giving. You should go even further - show code of the compilers, ask him about the actual data structures, how they do multithreading. Every conference gets him to do that same "what is new in TypeScript" (or C# before that) that every intern can present. Let him talk about the internals, the hard stuff that very few people know
My understanding is that @Jon is not talking about porting Web Forms to ASP.NET Core. He is talking about server-side component framework as opposed to the inferior Rails MVC model. For example Node.js gets server-side React (modern framework that is ideologically close to Web Forms and very far from ASP.NET MVC)
@MadsTorgensen So you think the nullable reference may be useful without the non-nullable part? It always seemed to me that it would be useless without it but I never gave it much thought. I do read the design notes from time to time and occasionally comment on them. The nullability tracking ones always scared me. The psychological aspect of declaring all code out there legacy even with a compiler flag is just too much. Now Roslyn analyzer is certainly less intrusive and may be a good idea but still would you put it in new projects by default? If you do it is not much different from a compiler flag, if you don't will people use it enough to justify the investment in this feature and the introduction of nullable reference types? And again what about all the courses and tutorials? I notice people in discussions about new features easily dismiss that last part. I think it is really serious since C# is already been criticized for becoming too large and complex and hard on beginners and for the long-term survival of the platform the community should not lose new members to stuff like Node and Go. Frustrating newcomers is not a non-issue.
The null checking is quite scary to me. The ! idea is sound but it is disgusting on syntax. The idea to make the default non-null would be cool if this was C# 1.0 but not now. You have to either skip some warnings, spit a lot of warnings or add a flag for old code. Option 1 is confusing for the user because he won't know when he can depend on the compiler to check the nulls. Option 2 is directly bad since warnings are not much different from introducing an error and that amount of warnings is just insane. Option 3 is bad because it turns perfectly fine code into legacy code in 1 second when C# 7.0 is released. I know I'd be quite annoyed by the feeling of guilt you will bring upon me. And what about all the learning materials out there? Suddenly newcomers can't even compile that code. I'd rather not have any null checking feature than have any of the current options.
BTW pattern matching and tuple/record syntax have been my top requests for C# since C# 5.0. I am glad they are coming.
Glad to see new features coming to Web Forms. The only thing I am sad about not getting is the new save & refresh development model that is introduced in ASP.NET vNext. It would be really cool if you can somehow make it happen.