i feel like this line from zig zen shows some of my reasonings for being against that ``` * Only on
i feel like this line from zig zen shows some of my reasonings for being against that
Lwe want people to use these safer types because they would be less error prone
Land more readable
Kyeah this makes sense. Overloading void* and IntPtr is a bit tricky (and in modern code you'd prefer nint but whatever)
Lwe dont want newcomers to just fallback to the unsafe API when they would probably be happier with the safer one, if they learned how to use it
KYes, but this is out the window given all we're doing is providing one way for each way C# provides us
Ayeah i have been moving towards nint, I wrote this code before I was aware that
IntPtr == nintwhich is why it is like it is, i should change itKlike there's multiple obvious ways to represent a data structure that does this in C#, and so we provide one obvious way to go from each possible obvious data structure design to one obvious call pattern in Silk
Kit's not on us to reduce the bullshit C# has layed upon itself for years.
KI think (might be wrong) void* implicitly converts to nint so
Pyeah this is my reservation in providing both. like yeah i'm content in doing so, but also
- please use the better types
- you can still use the better types in exactly the same way as if you weren't
Ahmm you might be right
Mthink of it this way, if we were the BCL, we'd have two overloads, like they have overloads for byte[] and Span<byte>
Knot really
Kbyte[] and Span<byte> are for legacy reasons
Mi suppose that's true
Pthen again it is my intention to have things like the ReSharper/Rider plugin help out a lot in saying "you're using unsafe, wanna use the better, more concise way?"
KBCL has mostly decided that Span<byte> is a strict improvement to byte[] and done that everywhere.
I might be wrong / outdated here but I don't think new APIs are introduced with
I might be wrong / outdated here but I don't think new APIs are introduced with
byte[] where Span/ROSpan make more senseK(sometimes maybe for equality with old legacy APIs)
Pyes 100%
PAND GUESS WHAT
Lin an ideal world, rider/resharper would autocomplete parameters for all the types that are implicitly convertible to
Ptr<T>, but i dont think its smart enough to filter by thatPARRAY IMPLICITLY CASTS
PJUST LIKE HERE
PHUZZAH
Mokay, i reckon if you understand unsafe then it is an easier bridge from byte* to Ptr<byte> than it is for someone who's a beginner and uses byte[]
Pyou can do that in a ReSharper plugin though
Pi've seen plugins do that
Pi.e. we could put
thing.AsPtr2D at the top of the list
Mso providing unsafe overloads seems excessive
Lthats kindof why i prefer the name
PtrLike<T> or maybe PtrRepresentable<T> to be even more verbosePyeah the name originally was PointerLike
Pinspired by numpy actually
LPtrRepresentable<T> would indicate that whatever you pass in can be represented by a pointer, but its kindof a mouthful to type?Mthat would kill people to type
Pit's also physically difficult to type
LPtrBacked<T>?P
La pointer is backed by a pointer, an array is on a surface level backed by a pointer
Mi feel no matter what, a name itself isn't gonna give you enough information to grasp it, but i'm not saying this from a position of enlightenment
LPtrBacked<T> would probably let the "knows just enough to be dangerous" crowd intutiively realize arrays work hereP100% agree, and if that user doesn't have the due diligence to read one documentation page then i don't want to support that user
Lbut we would still need ample docs
Mlike this is all working under the assumption that someone can just pick up and use silk without reading pages and pages of docs
Li mean thats how i started
Mwhich just isn't true
Li didnt read a lick of documentation
Land had no unsafe experience
Ljust learned as i went poking about with the overloads
Anot providing unsafe overloads causes problems though
it will drive away users like me, so granted not many, but it will mean i will most likely end up switching back to opentk or writing my own which do provide unsafe overloads
my library's internal implementation has no concept of arrays or safe or whatever
the safe overloads are merely a wrapper for unsafe ones, and it uses the advantage that silk is entirely unsafe to work well
it will drive away users like me, so granted not many, but it will mean i will most likely end up switching back to opentk or writing my own which do provide unsafe overloads
my library's internal implementation has no concept of arrays or safe or whatever
the safe overloads are merely a wrapper for unsafe ones, and it uses the advantage that silk is entirely unsafe to work well