okay, i reckon if you understand unsafe then it is an easier bridge from byte* to Ptr<byte> than it
okay, 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
Lit will be the same API,
T* implicitly converts to Ptr<T>Myeah
Mwhat beyley said
Lit will still be unsafe, just with some different names
P
KWondering why. I get the usability question, but there's not really any concerns out of it being the wrong type?
Mmaybe PtrLike is fine
Lim not a big fan of
PtrLike, an array in C# land isnt really "like a pointer" to most peoplePit's a good thing we have C&C tomorrow haha
Ai'm not so sure implcit conversion is a good idea
personally i think at the point you are relying on implicit conversion, your api should have a redesign
i used to use implicit conversion, realized it was causing all sorts of problems, readability included
and rewrote everything to be explicit
personally i think at the point you are relying on implicit conversion, your api should have a redesign
i used to use implicit conversion, realized it was causing all sorts of problems, readability included
and rewrote everything to be explicit
KI would like to suggest PtrRpr just for more fun when showing others my code
Li think
PtrBacked is the clearest name without being hard to type
Vperksey#0000
it's worth noting what we're discussing here is not Silk.NET 3.0. This is SilkX, a completely different library. there is still room for another contributor to create a different library to propose that it gets blessed as 3.0
Original Message
Quoted by perksey#0000
Pplease show us how it's done
KI get this, but really this is just how C# works. We don't have traits or associated types or anything cool, so we have to make do with what we got
Ljust to confirm, we moved back C&C an hour, right?
KI have no idea
Lwe should probably confirm that
KSome send the discord timestamp please
Pyes an hour, hoping that my family don't arrive during
Lsend a discord timestamp
Pmmnt
PAugust 5, 2023
P10am PST