but generally namespaces exist for a reason and i usually have a really hard time conveying that to
but 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
Mhard to tell, but i think this impl is just recursing
Mmaybe i'm just doing the pattern slightly wrong and the JIT doesn't get it
Mshould we have interfaces for the static methods on primitives? i guess i can implement them explicitly to discourage direct use
D
Had no dramas updating. (Though nuget restore went wonky and I had to update twice. 
)Manother optimization dead-end:
for T=
for T=
int, JIT attemps to lower it, but doesn't realize that int.IsCanonical always returns true, so the entire method should become mov eax, 1; ret 0xcMtanner pls fix /j
Mare static virtual interface methods meant to not be callable from inside the derived type?
Ki think they should work?
Knot 100% sure
P@grifon.petre how much bandwidth do you have atm
Pi want to nerdsnipe someone else into writing a competing solution to the overload problem
Pso that we have multiple prototypes to try out in a short timeframe
Mit don't work!
Khuh
Pyou need a TSelf
Kthat almost feels like a bug lol
Myeah its such a strange design decision
Kthe static abstracts can be called from the member type but also i guess those have a separate declaration on that type
Myeah
Mi wanted to use interfaces to reuse code