doesn't appear to be any automated ones
doesn't appear to be any automated ones
Pso there is technically no precedent here
Knot because we will generate 10 overloads for each possible T? Or because the APIs don't have any
PBuildTools does not generate any Silk.NET.Maths or System.Numerics overloads today
Twe'll likely have some APIs where it can minimally make sense for integers though
like
like
Log2(int)hrm I'll think this over but it's annoyingly a great argument for making more types. Hard to imagine what the rest of the types look like if we were to have Point + Vector. There is some interesting properties if we separate there also 
KAlso thanks as always Tanner for discussing all this and sharing your wisdom :)
TSure thing! And I’m definitely not always right nor is the BCL and it’s entire possible there’s alternatives that no one has considered yet.
I’m sure silk will end up with something that satisfies most of the user base regardless of what’s decided
I’m sure silk will end up with something that satisfies most of the user base regardless of what’s decided
Nare there any plans to make these apis distinct between namespaces?
Nor is this a case of me cramming everything into one file
Pare there any plans to make these apis distinct between namespaces?I think you've answered your own question
Pnamespaces are the language's built-in feature for disambiguating APIs
Nah i suppose i had a bit of a brain lapse
Nmy bad
Pwow, that worked?
Phaha no worries, not the first time we have got that complaint
Ni was just a bit concerned because this doesnt look the best but its not the end of the world
Nmigrating some of my code to the silk apis
Pyeah, there are other things you can do as well like
using SpvCompiler = Silk.NET.SPIRV.Cross.Compilertrue
Pbut generally namespaces exist for a reason and i usually have a really hard time conveying that to people
Pprimarily because unlike something like C++, people don't really think about them in C#
TNoting, however, that if two namespaces are expected to be commonly used together, it’s generally best practice to avoid conflicts and avoid explicitly disambiguate the real name instead
TNo clue if that’s the case here or not, but if it is then API review would ask us to reconsider the names
Pit’s an odd case
Pespecially considering we automatically trim prefixes
Pperhaps if we’re concerned about namespaces we shouldn’t do that
Pjust feels wasteful
Pperhaps we could add global usings with the prefix in to help for these cases
TIt might be a one off case where it’s worth it. Compiler is itself fairly generic as a term, so SpirvCompiler makes it “clearer” and reduces conflict chance
I’d personally expect something just named Compiler was probably abstract
I’d personally expect something just named Compiler was probably abstract
TI know ClangSharp has the capability to do one off remapping and aliasing. Might be worth it for the silk tool as well?
TWould probably also make it easier for enums and other cases where it’s PREFIX_3NAME and such
Pyeah we have one off remapping as well, we just don’t really consider names beyond the individual project rn.
TGotcha
Piirc we currently do implicitly add the prefix when the name isn’t legal in C#
Pe.g. the numbers
Ago the direct3d route,
ISilkDotNetSpirVCrossCompiler
Mwhy is there no Unsafe.Copy from ref to ref
TTypically you’d just use span for such cases
Or buffer.blockcopy or similar
Or buffer.blockcopy or similar
Mtrying to reuse code for vectorized equals for all of the primitives... time to see if the JIT can lower this
M*ignore the obvious errors
Mi got it to work by removing the loop
Mshame it can't be unrolled but, good enough
Pwhat code can’t it unroll
Msequenceequal at the bottom
Mbasically, the JIT can't inline the length in SpanHelpers.SequenceEqual because it's a mutated variable
Pyou can probably make an unrolling impl by recursion + inlining
Mmy solution, since this method is only meant to handle scalar lists of length 1 to 4, is to hardcode the equality checks
Mgod help me
Dcongrats on getting v 2.18 out
Dtime to update "all" my things