How will this possibility change the way we write C#? Why is it being introduced? I’ll try to address these questions today

Interfaces today

As we all know from the current version of C#, interfaces allow to define a kind of contract, which must be respected by a class implementing it. Today interfaces can only contain definitions of methods (with no body). These methods are then actually implemented by concrete classes. If a class doesn’t implement all of its interface’s methods, compiler produces an error.

What’s problematic in this approach? Assuming that you have the following interface and class(es) implementing it:

With time, you may want to extend IDeveloper interface by adding a new method, for instance:

Now you have a problem, because the new method must be implemented in all places where the interface was used. Compiler gives you an error as long as it’s not done:

If your interface is used in many places, also by another teams or developers (which is often the case in reality), this is a breaking change

It may be really painful, depending on how extensively your interface is used. In any case, all classes based on the IDeveloper interface must implement the new LearnNewLanguage(string language) method. Only then the code compiles.

One of the reasons for introducing into C# default interface methods is to avoid such breaking changes scenarios

Default Interface Methods

As we can read in the feature’s design notes, an inspiration for it is a similar concept already alive in Java – Default Methods.

The main idea of this new C# feature is a possibility to provide a default implementation of an interface’s method.

Realization in C# 8.0

In our example using C# 8.0 we’ll be able to implement it as follows:

In that case, our class implementing the IDeveloper interface can legally not implement this new method and there will be no compilation error:

Notice that it only works when BackendDev is contextually treated as IDeveloper. It means that a class doesn’t inherit members from the interfaces it implements:

What about multiple inheritance?

As some of you probably realized, this new feature exposes C# to a multiple inheritance problem (also known as Diamond of Death). So far C# didn’t have this issue, because we can only inherit from a single class. We can implement multiple interfaces, but so far the interfaces couldn’t provide methods’ implementation. Because of that, there was no Diamond of Death possible. Soon it’s gonna change

Diamond of Death in C# 8

In case of C# default interface methods we may illustrate this issue with the following code:

Please note that the syntax or places in which compiler generates errors may still change in the final feature’s version.

To better illustrate this Diamond of Death example, take a look at the following diagram:

The question is: which method should be called in such case?

Solution: most specific override rule

C# 8.0 will solve this issue by introducing the most specific override rule. It means that in our case illustrated above, the compiler will issue an error and won’t let us do this.

To avoid this ambiguity, we’ll be forced to implement or override LearnNewLanguage(string language) in IFullStackDev interface. Only then it will be considered the most specific version of the method in the interfaces hierarchy we have. It will then be used when calling the method on objects contextually treated as instances of IFullStackDev. We could also implement it directly in the Dev class and use the class (not interface) type. It would then call the most specific method from the class. This way multiple inheritance issue will be eliminated.

Compiler for the rescue

There are a lot of other potential ambiguity scenarios that may take place after introducing into C# default interface methods. You can check all of them with potential solutions well-discussed on GitHub.

The general assumption is that all code which may lead to issues related to default interface methods implementations is detected by the compiler. In effect, we should get appropriate errors when compiling the source code. That way, programmer can fix all potential conflicts directly when these arise.

What about .NET Framework?

What’s interesting with default interface methods is that it requres changes in the runtime. According to current assumptions, it means that this feature will not work with .NET Framework! Only CoreCLR and Mono stack runtimes are going to receive these new updates.

Summary

As the motivation for introducing into C# default interface methods the language team members mention possibility to interact with some Android and iOS APIs, which already support such feature. They also claim that C# will get the traits programming language feature with default interface methods.

In my opinion this is the most controversial from all C# 8.0 new features. It completely changes something which was obviousness for the developers for years. Probably we’ll see less breaking changes issues when the interfaces are extended, but looking on the list of issues and edge cases it produces… Maybe assuming it already works in a similar way in Java we should just accept it?

Another interesting, .NET-specific aspect is that this feature will not work with .NET Framework. It’s probably the very first moment when the difference in pace between .NET Core and Framework is so explicit.

I’m also very curious about the performance implications of default interface methods. I’ll for sure be following this issue on GitHub to see how it evolves

What do you think? Is it a good idea to introduce default interface methods into C#?

The post C# 8: Default Interface Methods Implementation appeared first on CodeJourney.net.

Let’s see how this tiny feature is supposed to make our life easier

Goal of slicing

The main purpose of introducing slicing into the language is to make working with arrays and strings easier.

Currently, when you want to retrieve a fragment of an array (X elements from the array, located for instance in its middle), you can use LINQ, i.e. combination of Take and Skip methods. You can also create some extension method to provide kind of slicing.

To illustrate the current way, using LINQ to retrieve only 2nd, 3rd and 4th elements of an array looks as follows:

C# community and designers decided it’s not convenient enough, so are now adding to C# 8 indexes and ranges (in order to provide slicing)

Index

C# 8.0 comes along with a new object – System.Index. It’s a structure internally and looks as follows:

What’s interesting here, is that the constructor takes the value of the index and boolean flag fromEnd. Let’s see how we can use it in practice:

While the first printed value is nothing special, as you can see we can now use the hat operator (^) in order to index from the end. The following also works:

It means that the ^ operator is a syntactic sugar for Index. I allowed myself to check the IL produced:

As we suspected – an instance of Index is created, passing 3 as value and true as fromEnd (see the constructor parameters above).

Range

Another concept which uses Indexes is a new structural data type – System.Range:

As you can see, it really uses Indexes. We can even try creating it on our own:

This doesn’t really make extracting data from the arrays better than Skip-Take LINQ, does it?

Fortunately, there’s another friendly C# language element introduced called range expression. It can be written as x..y and used directly for indexing:

This looks much better! Let’s see how C# compiler translated our 2 lines of code by looking at the pseudo-C# IL produced:

Even though we could achieve the same with much less LINQ, C# compiler does a lot of stuff for us, keeping our code simpler to grasp.

Ranges in strings

All these operations apply also to strings:

Ranges in foreach loop

Next interesting usage is in the foreach loop:

Summary

I see these “little” C# 8 indexes and ranges as another helpful feature. It’s less breaking and controversial than nullable reference types, still making us write less C# code in the future.

If you’d like to dig the feature even more, I encourage you to read the discussions about it on GitHub, which I always find very interesting

Developers, what do you think about C# 8 indexes and ranges?

The post C# 8: Slicing with Indexes and Ranges appeared first on CodeJourney.net.

Learn about building C# 8.0

C# 8.0 is going to be the next major release of C# language. It should be released by the same time as .NET Core 3.0.

What I find very interesting is C# language GitHub repository. Among others, you can find there very interesting notes from C# language design meetings If you filter well, you can also list so called “proposals”, which are current candidates for new C#’s version (or sub-versions) features. By clicking here you can list C# 8.0 candidates.

I will publish a separate post regarding each feature which I find particularly interesting

Nullable reference types

First of the C# 8.0 features I’d like to discuss are nullable reference types. It seems it’s going to change the way we write our code, so it’s worth knowing this feature.

A bit of history – NullReferenceException

Consider the following code:

Guess what happens after executing this as a console app? Of course, our favorite NullReferenceException is thrown:

In this case, jsDev.LastName is of course set to null.

NullReferenceException has been a nightmare for thousands of developers (and users) for many years. What if, in the cases like our example, we knew before that in this place our object might be null?

New world – #nullable enable

For that purpose, C# development team is introducing nullable reference types. In essence, it makes reference types (like string) non-nullable! However to not be a tough nut to crack, all issues related to assigning null value to non-nullable reference types are presented as warnings, not errors.

In order to use this feature, you need to enable it. You can do it with a preprocessor directive #nullable enabled. We can do it directly in the source code file. In the future, it should also be possible to enable it on project level.

Notice what happens when we enable it in our example:

We’re still able to compile, but this nice warning is displayed As soon as we initialize LastName property in the constructor, the warning disappears:

If you try to cheat, it still works like a charm :

But hey… what if you actually want null in this particular string? You need to explicitly mark your reference type variable as nullable. You probably recall nullable value types like int?, don’t you (read this post if you don’t remember the difference between value and reference types)? Now you can do the same with non-nullable reference types:

Nonetheless, in such case, the compiler still takes care of us:

The final fix is quite obvious – we need to check for null first:

At this stage all warnings finally disappear. You can find the finished source code here.

Nullable reference types in IL

The only thing I found in the IL code compiled from source code with #nullable enabled directive was NullableAttribute applied to properties:

It seems that nullable reference types are implemented by applying this attribute to variables, which is only used by the compiler (runtime is not affected).

Summary

I’m really excited about nullable reference types in C# 8. I personally feel that it even introduces some clarity in the language – we’ll have explicit declarations for nullable value and reference types. However, in more complex scenarios it may bring some confusion in regards to reference types and using “?” character (like generics or collections – see Jon Skeet’s post for more details). For sure it’s a significant step towards eliminating issues with exceptions caused by null references.

What do you think about nullable reference types? Is it a good direction in which C# language is going? Share your thoughts in the comments!

The post C# 8: Nullable Reference Types appeared first on CodeJourney.net.