Pmost of our users don't want that though, so we will encounter the education problem still.
Pbut again, my intention is to have a "Silk DSL 101" page that just tells you everything you need to know in using these wrappers
Msilk documentation already isn't any good, it can't get worse
KIt's the same problem Span introduces though. These are advanced APIs, you spent hours digging through docs. Read the 2 lines the intellisense will give you once you hover over the Ptr type
Pagain we literally can't ship 3.0 until we have docs
Pthe Working Group has decided that
Aif you need docs written you know who to ask heh
Mwhat a daunting name
Mthe Working Group
Ai've been meaning to write new tutorials I've just been juggling around 6 projects at once
Pit used to be the ARB - API Review Board
Li 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 listMso 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
