Pcode signing did not survive the macOS CI transition, will be pushed this evening - still in bed atm
Aah ok
Pthinking about it more, making a source generator where you can pick your own overload style will be super easy, barely an inconvenience
Pi haven't once used the workspace-level mod functionality in silktouchx, in fact i'm actively working on disabling it by default
Pwhich means we're basically just storing pure syntax
Mmy only concern is that it would complicate developing libraries that depend on silk
Pso consider: we simply create an archive containing all the generated syntax, you install
Silk.NET, and the source generator contains the same mod pipeline as in SilkTouchXPi mean... yeah that's a valid concern
Pidk how CsWin32 does this
Pis sergio in here?
Pit appears not
Pbare with
Pok sergio is on the Eurasian plate so I will assume that he is winding down for the evening and will take a while to respond
Pbut it's a valid concern
Pi suppose we could do MSBuild magic and have it as an MSBuild task instead of a source generator
Pa Silk.NET.dll would be created at build time, all the prebuilt dependencies already referencing that, and each dependent containing metadata on the configuration needed to generate the source that goes into that DLL
Pbut that is no longer Super Easy, Barely an Inconvenience
Pit appears CsWin32 exposes an option to expose the bindings as public
Pso i guess the idea is you make your own common package
Mi hate that
Pnot really great if you want to make an ecosystem
Pyeah
Plike how would SilkCommunity work
Mwith sourcegen it seems unavoidable that you'd end up with tons of duplicate internal types
Pthe only other possible alternative i can think of is having a mega Silk.NET.dll that contains every possible combination of overloads and bindings, and then just generating a ref assembly on the fly so you don't see the ones you don't want
Mthat's horrible but also kinda great
Mtype forwarding?
Mcan we use that?
Pdon't need to, the assembly that roslyn uses would just be a shim or even just a cut down version of the big assembly
Pand then once roslyn has read that, we swap it out for the full-fat one using MSBuild
Mwill it kill the CLR to have that many overloads?
Ponly if they're used
Mhmmmmm
Myeah this seems kinda workable
Pthe user would have no idea that those other functions even exist, but they'll still be there for the libraries that do need them
Pthe only thing that'd be hell would be trimming times would go 
Pbut thinking about it i don't think we'd even need a mega Silk.NET.dll for this
Pwe could just have it as standard in our packages, but dormant unless you turn it on
i.e. the default experience is you get the reference assemblies for Ptr etc, but you can configure it Not To Do That
i.e. the default experience is you get the reference assemblies for Ptr etc, but you can configure it Not To Do That
Mbtw did you check the generic math proposal
Pwill do now
Kfirst comment from me already is why does LengthSquared need a new type? requiring INumber is enough
KId rename SquareRoot for consistency with existing symbols in the bcl
MSystem.Numerics uses Sqrt
Mwait
Mno system.numerics uses SquareRoot. huh
Mwhat do you mean by new type
M(x*x)+(y*y)+(z*z) is very likely to overflow with integer types
Mso yeah i could jsut leave that burden onto the user, but that is 90% likely a mistake
Msame as DistanceSquared
P- Given that we have both Point and Vector, surely the latter is assumed to be euclidean and therefore should have length stuff ergo being float only, not just any INumber?
- readonly structs all the way, especially now we have withers
- definitely prefer static methods on non-generic types, this was an explicit choice in Silk.NET.Maths so that you wouldn't need to repeat the generic unless you absolutely had to
thing = Vector2.Abs(thing)is much cleaner thanthing = Vector2<T>.Abs(thing). in most cases extension methods just work also, but you do raise a good point that sometimes you will have to repeat the generic but i'm okay with this. - not related to the proposal, but do BigInteger and Complex have the generic maths interfaces implemented? Silk.NET.Maths supports these today.
#if NET8_0this is assumed if we're targeting 3.0. 3.0 will target the latest even-numbered SDK at time of release.- happy with
Sqrtinstead ofSquareRoot. generally prefer the names that we've used inSilk.NET.Mathsbecause we've already bikeshedded these. Because the type of T has to be narrowed to IFloatingPointIeee754<T>, we can't actually implement the interface on Vector3<T>.I don't think Silk.NET.Maths ever did support Vector-as-Scalar as we had once thought of doing (i.e. allowingScalar.Add<Vector3<float>>(l, r)) so we can live with this. it's cursed anyway.Ideally, this should be vectorized. In practice, that's a lot of work.no more work than we were prepared to do for 2.0Extension 3: INumber<Vector3<T>> Implementationyeah I guess?Extension 4: Directional static propertiesif we're doing something like this it should be an extension method that allows the specification of the coordinate system, not a simple property.Extension 5: Convenience methodsyep fineExtension 6: IUtf8SpanFormattable (.NET 8)if someone's willing to do it then yeahImplicit cast to Vector2<T>, drop the Z componentshould be explicit- generally make sure you have API parity with Silk.NET.Maths. Silk.NET.Maths is the one area where we don't actually need to do any surface API changes (generic maths notwithstanding) because it's pretty solid, and changing anything here would do weird things to user expectations.
documentation/proposals and make a more formal proposal like the WIP one in #1727, making rationale and alternatives (and the discussion points thereof) clear; if you want this in 3.0