.NET 7 is just around the corner and is already bringing a lot
Among those improvements, a small specific one is really elegant and may help you in writing methods that are dealing with numbers in a better way: the new INumber<T> interface.
Setup 🧰
This feature is still in preview so, to try and run the following code you will need to create a new project using .NET 7 and enable the preview features.
The .csproj for my console app looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net7.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<LangVersion>preview</LangVersion>
</PropertyGroup>
</Project>
Use case 🔎
Let's image that we are building a shopping app and we want to check out a cart. For now all prices TTC are round numbers so we wrote the following method to sum it all:
int CartValue(int[] numbers)
{
var result = 0;
foreach (var i in numbers) result += i;
return result;
}
We later use it in our logic to compute the value of our cart:
var prices = new[] { 1, 2, 3 };
var sum = CartValue(prices);
And it works great !
Until ...
It worked great but now we also have the shipment and other taxes that we must sum along with the price and our method no longer works:
var pricesWithTaxes = new[] { 1, 2, 3, 1.5 };
var sumWithTaxes = CartValue(pricesWithTaxes);
// ^ This is not an int[] and won't compile
We may be tempted to rewrite the CartValue method to accept double[] instead of int[] and then cast all numbers to double to fix this issue, but we also noticed that .NET 7 is available and there is a brand new feature for this
Introducing INumber
From now on, numbers are implementing the INumber<T> interface which exposes underlying math concepts such as the notion of zero, addition, one, etc. for numbers, regardless the type of T
In our case, it means that both int and double are INumber exposing the same concepts (although not the same values for those)
Let's rewrite our method to accept an array of any number:
T CartValue<T>(T[] numbers)
where T : INumber<T> // <-- Don't forget the constraint!
{
var result = T.Zero;
foreach (var i in numbers) result += i;
return result;
}
And just by using a generic to specify that the provided array is a number, our method is working great again and the previous code should now compile!
There are a lot more than just this interface in .NET 7 and I recommend you to check out the .NET 7 Preview blog that Microsoft has been writing about the next version of the framework
I hope that you learned something valuable, have a great day!
Top comments (3)
This is a nice change, but it should be pointed out, this will likely still involve casting all your numbers to double. Just going off the syntax, T in T CartValue(T[] numbers) will always resolve to a single type for a particular call, meaning that all the elements in your array have one type. This just saves you from having to rewrite CartValue for different numeric types—it almost certainly does not smuggle in heterogeneous arrays.
I know this is just your example program, and example programs are always contrived. After all, business software probably shouldn't be polymorphic on money representation. And in my opinion, you shouldn't use doubles to represent money.
That said, this is a nice addition, actually something I'd despaired a bit about not having before. Particularly the inclusion of T.Zero.
You are absolutely right, thanks for pointing that!
Indeed my example might not have been the most explicit one, I should have talked about summing only taxes (double) to avoid confusion
The reason I like this is that it lets you turn
foldintosumeasily, something like,or however that syntax is going to work out. Then there are a lot of other things you can do with that sort of pattern. Being able to write more complex stuff, like weighted average and standard deviation, is pretty hot.