Should System.Numeric.Vectors be included in .NET Standard 2.0?

[weshaggard]

Given that System.Numerics.dll was included in the assemblies we intersected to produce the initial set of APIs that pulled in all the Vector APIs as well. However we System.Numerics.Vectors also contains Vector<T> which isn't part of .NET Framework 4.6.1 which causes things to fail if folks depend on this (like SpanExtensions in corefxlab which asp.net folks are using). So we have a number of options to fix this:

1. We leave this alone and folks consuming Vector<T> from a netstandard library will fail at runtime on .NET Framework 4.6.1 (current situation).

2. We continue to ship a nuget package for System.Numeric.Vectors that has a partial OOB that provides support for Vector<T> on .NET Framework 4.6.1. This will OOB will override the System.Numeric.Vectors facade that already ships inbox but doesn't contain Vector<T>.

   1. We continue to ship the Vector types in netstandard2.0 but allow the library package to deliver only the implementation for .NET Framework 4.6.1
   2. We remove all the Vector types from netstandard2.0 and ship the ref and implementation in the System.Numerics.Vectors nuget package.

There may be some other varations of these options but I think this covers most of them. Given these options I perfer option 2ii but I'm curious what others think.

cc @terrajobst @ericstj @mellinoe

[mellinoe]

I was not aware that we actually included Vector and Vector<T> in .NET Standard; I don't think those should be a part of the standard itself. The other types, Vector2/3/4, Plane, Quaternion, and Matrix4x4/3x2, should be. They are actually implemented in .NET Framework, whereas Vector/Vector<T> are not. We should still be able to support Vector/Vector<T> on (top of) .NET Standard through the System.Numerics.Vectors nuget package.

[weshaggard]

The other types, Vector2/3/4, Plane, Quaternion, and Matrix4x4/3x2, should be.

We cannot easily add part of a contract like this to the standard without have various rough edges in our experience. So I think we should remove everything that is part of System.Numeric.Vectors from the standard.

[mellinoe]

What are the rough edges?

[weshaggard]

Lets assume folks reference "System.Numeric.Vectors" 4.3.0 package and they referenced "NETStandard.Libary" 1.6.0 and they upgrade just their "NETStandard.Library" package to 2.0.0. Now they will get ambiguous type references for the types that are in netstandard2.0 and the Vectors package. They can fix it by update the reference to the later System.Numerics.Vectors package, but if the vector types aren't in netstandard then this scenario will work without any problems. They can reference the old Vectors package and the new netstandard package and continue to work.

[tannergooding]

@weshaggard, won't that philosophy prevent us from moving new APIs into .NET Standard?

[tannergooding]

Basically (the way I view it) most new APIs or features, like System.Numerics.Vectors (or System.Collections.Immtuable), will end up in their own packages from the start. If that is the case, and we follow the "they will get ambiguous type references" logic, then we will never be able to merge new APIs, regardless of how well liked/used they are, back into .NET Standard.

[weshaggard]

@weshaggard, won't that philosophy prevent us from moving new APIs into .NET Standard?

No. This one is a special case in that only part of it is supported on some platforms right now so we cannot easily ship part of it in and part of it out. For future versions we will move the entire library into netstandard once we decide to add it to the standard and then we will ship a shim assembly that allows folks that reference the older identity to unify. That shim assembly will win any file conflicts when you are referencing the newer netstandard and an older individual library package. Once it comes into the standard any new APIs added to types will have to be added as platform specific (i.e. netcoreapp) or wait for a new version of the standard to add them.

[tannergooding]

@weshaggard, do you mean that the intrinsic implementation (that is, hardware acceleration) is only available on some platforms? I thought we had explicit software implementations which should work on all platforms regardless.

[weshaggard]

Vector<T> is not inbox on all platforms, in particular .NET Framework. We do have a version of it that ships in the nuget package but by doing that we cannot correctly handle the file conflict issue by shipping a shim for System.Numeric.Vectors in the NETStandard.Library package. Which means we get into to a state where we have broken projects when folks update the NETStandard.Library package but not the System.Numeric.Vectors project. For netstandard APIs we need them to be fully inbox on platform and their platform needs to provide a netstandard.dll facade that type-forwards them to wherever they live in that platform.

[tannergooding]

Thanks for the explanation. That clears it up a bit more 😄

[weshaggard]

The PR to add the vectors package back is dotnet/corefx#17350.