yeah this makes sense. Overloading void* and IntPtr is a bit tricky (and in modern code you'd prefer
yeah 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 == nintlike 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[]SpanROSpan(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>ARRAY 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
Mso providing unsafe overloads seems excessive
Lthats kindof why i prefer the name
PtrLike<T>PtrRepresentable<T>yeah the name originally was PointerLike
Pinspired by numpy actually
LPtrRepresentable<T>that would kill people to type
Pit's also physically difficult to type
LPtrBacked<T>
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>100% 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
Lit will be the same API,
T*Ptr<T>yeah
Mwhat beyley said