Default implementations of interface members
Today, once you publish an interface it’s game over: you can’t add
members to it without breaking all the existing implementers of it.
In C# 8.0 we let you provide a body for an interface member. Thus, if
somebody doesn’t implement that member (perhaps because it wasn’t there
yet when they wrote the code), they will just get the default
implementation instead.
interface ILogger
{
void Log(LogLevel level, string message);
void Log(Exception ex) => Log(LogLevel.Error, ex.ToString()); // New overload
}
class ConsoleLogger : ILogger
{
public void Log(LogLevel level, string message) { ... }
// Log(Exception) gets default implementation
}
Correct me if im wrong …
Virtual interfaces ?
Isn’t this the equivalent of introducing multiple inheritance with abstract classes ?
What happens when two interfaces define the same default and its not overriden by the deriving class ?.
interface ILogger
{
void Log(LogLevel level, string message);
void Log(Exception ex) => Log(LogLevel.Error, ex.ToString()); // New overload
}
interface ILoggerB
{
void Log(LogLevel level, string message);
void Log(Exception ex) => Log(LogLevel.Error, ex.ToString()); // New overload
}
class ConsoleLogger : ILogger : ILoggerB
{
public void Log(LogLevel level, string message) { ... }
// Log(Exception) gets default implementation
// but which one ?
}
Granted not a great naming example but the question remains
Switch expressions
I like this because i use switch case from time to time. Actually i really like this one a lot.
yeild
I hardly ever use this because i think that changing the normal way method scope works in general leads to bugs and is hard to debug. When there is a problem in general it can add a huge amount of complexity to code and i cant even remember the last time i used it. That said it does look pretty neat.
Note.
Most of the C# 8.0 language features will run on any version of .NET. However, a few of them have platform dependencies.
Async streams, indexers and ranges all rely on new framework types
that will be part of .NET Standard 2.1.
,
.NET Core 3.0 as well as Xamarin, Unity and Mono will all implement
.NET Standard 2.1,
but
.NET Framework 4.8 will not.
This means that the types required to use these features won’t be available when you target
C# 8.0 to .NET Framework 4.8.