@akoeplinger is this the best way to make this work with the whole corelib reference infra?

@ericstj this would be the correct way assuming we want to keep the code in System.Numerics.Vectors.dll. The PR description says this is intentional and I haven't read all the PR history but I don't immediately see why this shouldn't just be moved into Corelib though.

moved

It doesn't need to be, so it isn't I suppose. Of course it could always be moved later. Thanks for the confirmation.

I didn't see any tricks folks are using to have GenAPI emit the ifdefs, or do a sepreate run to a different file. It looks like we just handle that by auditing the diff out of genapi and undoing any line changes that would remove the ifdefs. I'll add that to my list of features that would be nice to have to make GenAPI unsupervised.

@ericstj it will emit the ifdef, via https://github.com/dotnet/arcade/blob/0831f9c135e88dd09993903ed5ac1a950285ac96/src/Microsoft.DotNet.GenAPI/GenAPITask.cs#L158-L162

I think I have a slight preference for moving the code into corelib, if only for the fact that we then don't need Strings.resx in the S.N.Vectors assembly (makes it smaller)

I believe we intentionally don’t want to move code into corelib if not required. It increases cost and other considerations for all apps for something that doesn’t actually require special runtime support.

This has come up for other types as well recently and had input from @jkotas as well

Notably, most of the types except for Vector<T> don't even need to be in S.P.Corelib anymore (strictly speaking), as they aren't directly JIT accelerated.

The main reason they are is because of the interchange with Vector128<T> and the Vector128.AsVector128(...) and Vector128.AsVector2/3/4(...) extension methods that exist in the System.Runtime.Intrinsics namespace.

System.Drawing.Primitives would be an overall net negative and be much worse for the longevity of these types, particularly as one of the points is to be separate from System.Drawing and the general GDI+ concepts.

System.Drawing.Primitives was specifically created to carve out System.Drawing portion that does not depend on GDI+.

Users do not have a control over references to the individual libraries in NetCoreApp. I do not see why having these types in System.Drawing.Common affects longevity of these types. It is just our own internal layering consideration. We can always move them down if we find a good reason for it, but moving them up is not really possible.

The layering consideration is that System.Drawing.Primitives is itself largely "tied" to System.Drawing and is a legacy thing that new code largely shouldn't be using

System.Numerics.Vectors on the other hand is "modern" and new, its the thing people want to use instead and in place of Drawing.Primitives outside of back-compat concerns like what WinForms has.

I'd rather it stay as part of the S.N.Vectors ref assembly accordingly and just move it into corelib if that's better for perf than the partial facade. -- It makes explaining what and where simpler: S.N.Vector == modern, S.D.Primitives == legacy

The layering consideration is that System.Drawing.Primitives is itself largely "tied" to System.Drawing and is a legacy thing that new code largely shouldn't be using

I disagree. I think System.Drawing.Primitives should be the dumping ground for higher level graphics related stuff like colors that we think deserves to be in the NetCoreApp.

It makes explaining what and where simpler: S.N.Vector == modern, S.D.Primitives == legacy

We do not need to be explaining this. People reference NetCoreApp.

I disagree. I think System.Drawing.Primitives should be the dumping ground for higher level graphics related stuff like colors that we think deserves to be in the NetCoreApp.

This is already not the case. Most high level graphics stuff, especially non-legacy, comes from S.N.Vectors.

We do not need to be explaining this. People reference NetCoreApp.

Its something that comes up regardless, especially for people working in this space across the range of stacks that graphics touches (which is probably one of the few domains that is largely not exclusive to our runtime today).

I'm not hard set here and it probably doesn't ultimately matter, but I really don't think the System.Drawing.Primitives ref assembly is the right place to put this API. System.Drawing in general is a legacy concept and one of the main purposes of these new types is so that users don't have to deal with the System.Drawing types anymore, because they are "bad".