The reason of System.Numerics being a separate Assembly [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

System.Numerics assembly contains only two types (structs) BigInteger and Complex, the rest of built in Numerical types including (int, long, double ...) are all in the System.dll assembly.

Why such separation ? I can see for example in the declaration of two types from both Assemblies, for instance :

Double :

public struct Double : IComparable, IFormattable, IConvertible, IComparable<double>, IEquatable<double>

Complexe :

public struct Complex : IEquatable<Complex>, IFormattable

The implemented Interfaces here in the Complex type are all used in Double, and are all generally from the System assembly, so basically the interfaces implemented won't be the reason of that separation.

I still wonder what is the purpose behind this separation, they all numerical types, they are all built in, they all implement somehow the same interfaces from the same assembly, why such separation then, why wouldn't the BigInteger and the Complex types be in the System assembly alongside all other built in numerical types ?!

This separation is also accompanied with the fact that the System.Numerics types are really rarely mentioned in books and tutorials, and that costs a young beginner developer like me to ignore the presence of those types for a long time.

Edit: I don't mean by this question to talk about my opinion, I just don't understand this case, I ask this question to have more understanding for the platform.

Answer 1

They were added to the Framework much later than the other types.

So at some point, some team at Microsoft is creating these two types, and they have to make a decision: do we add them to an existing DLL, e.g. mscorlib.dll or System.dll, or do we put them into a new DLL.

I'm sure they considered all the pro's and con's.

Here are a few possible arguments in favor of the decision to put them into a separate assembly:

• they are rarely needed. Why increasing the size of an existing assembly with types that are rarely needed?
• Other people might have Implemented types called BigInteger and Complex. By not adding our implementation into an existing assembly, we are less likely to create problems for them (i.e. break their build).
• By putting them into a separate assembly, we can have a separate release cycle. We do not have to wait for the next release of the .NET Framework to release this assembly.

I am aware of the fact that all these arguments have counterarguments, but they did decide to create a separate assembly. As for the actual reasons, you would have to ask the team in question. That being said, many teams ask themselves the same question every time they want to add a type. The above points are often on the list of arguments considered.

Answer 2

Beside being introduced much after base-class libraries, they represent data types on which CPUs don't operate. Operators found in BCL can be executed directly on your CPU, such as addition, substraction etcetera. One notable exception is decimal type for which BCL has special consideration.

Second big reason in my opinion is that separating these types discourages their use on all platforms. You need to be specially aware of what BigInteger is before deciding to use it on your mobile phone or your tablet.