yeah i have been moving towards nint, I wrote this code before I was aware that `IntPtr == nint`whic

yeah i have been moving towards nint, I wrote this code before I was aware that

IntPtr == nint

IntPtr == nint

IntPtr == nint

IntPtr == nintwhich is why it is like it is, i should change it

Kai•8/4/23, 9:10 PM

like 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

Kai•8/4/23, 9:10 PM

it's not on us to reduce the bullshit C# has layed upon itself for years.

AAqua yeah i have been moving towards nint, I wrote this code before I was aware that ...

Kai•8/4/23, 9:11 PM

I think (might be wrong) void* implicitly converts to nint so

LLyris the Kitori we want people to use these safer types because they would be less error prone

Perksey•8/4/23, 9:11 PM

yeah 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

AquaOP•8/4/23, 9:11 PM

hmm you might be right

Maxine•8/4/23, 9:11 PM

think of it this way, if we were the BCL, we'd have two overloads, like they have overloads for byte[] and Span<byte>

Kai•8/4/23, 9:11 PM

not really

Kai•8/4/23, 9:11 PM

byte[] and Span<byte> are for legacy reasons

Maxine•8/4/23, 9:12 PM

i suppose that's true

Perksey•8/4/23, 9:12 PM

then 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?"

Kai•8/4/23, 9:12 PM

BCL 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 byte[]byte[] where SpanSpan/ROSpanROSpan make more sense

Kai•8/4/23, 9:12 PM

(sometimes maybe for equality with old legacy APIs)

Perksey•8/4/23, 9:14 PM

yes 100%

Perksey•8/4/23, 9:14 PM

AND GUESS WHAT

PPerksey then again it is my intention to have things like the ReSharper/Rider plugin hel...

Lyris the Kitori•8/4/23, 9:14 PM

in an ideal world, rider/resharper would autocomplete parameters for all the types that are implicitly convertible to Ptr<T>Ptr<T>, but i dont think its smart enough to filter by that

Perksey•8/4/23, 9:14 PM

ARRAY IMPLICITLY CASTS

Perksey•8/4/23, 9:14 PM

JUST LIKE HERE

Perksey•8/4/23, 9:14 PM

HUZZAH

Maxine•8/4/23, 9:14 PM

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[]

LLyris the Kitori in an ideal world, rider/resharper would autocomplete parameters for all the typ...

Perksey•8/4/23, 9:14 PM

you can do that in a ReSharper plugin though

Perksey•8/4/23, 9:14 PM

i've seen plugins do that

Perksey•8/4/23, 9:14 PM

i.e. we could put thing.AsPtr2Dthing.AsPtr2D at the top of the list

MMaxine okay, i reckon if you understand unsafe then it is an easier bridge from byte* t...

Maxine•8/4/23, 9:15 PM

so providing unsafe overloads seems excessive

Lyris the Kitori•8/4/23, 9:15 PM

thats kindof why i prefer the name PtrLike<T>PtrLike<T> or maybe PtrRepresentable<T>PtrRepresentable<T> to be even more verbose

Perksey•8/4/23, 9:16 PM

yeah the name originally was PointerLike

Perksey•8/4/23, 9:16 PM

inspired by numpy actually

Lyris the Kitori•8/4/23, 9:16 PM

PtrRepresentable<T>PtrRepresentable<T> would indicate that whatever you pass in can be represented by a pointer, but its kindof a mouthful to type?

Maxine•8/4/23, 9:16 PM

that would kill people to type

Perksey•8/4/23, 9:16 PM

it's also physically difficult to type

Lyris the Kitori•8/4/23, 9:16 PM

PtrBacked<T>PtrBacked<T>?

Perksey•8/4/23, 9:16 PM

Lyris the Kitori•8/4/23, 9:16 PM

a pointer is backed by a pointer, an array is on a surface level backed by a pointer

Maxine•8/4/23, 9:17 PM

i 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

Lyris the Kitori•8/4/23, 9:17 PM

PtrBacked<T>PtrBacked<T> would probably let the "knows just enough to be dangerous" crowd intutiively realize arrays work here

Perksey•8/4/23, 9:17 PM

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

Lyris the Kitori•8/4/23, 9:17 PM

but we would still need ample docs

LLyris the Kitori `PtrBacked<T>` would probably let the "knows just enough to be dangerous" crowd ...

Perksey•8/4/23, 9:17 PM

true

Maxine•8/4/23, 9:18 PM

like this is all working under the assumption that someone can just pick up and use silk without reading pages and pages of docs

Lyris the Kitori•8/4/23, 9:18 PM

i mean thats how i started

Maxine•8/4/23, 9:18 PM

which just isn't true

Lyris the Kitori•8/4/23, 9:18 PM

i didnt read a lick of documentation

Lyris the Kitori•8/4/23, 9:18 PM

and had no unsafe experience

Lyris the Kitori•8/4/23, 9:18 PM

just learned as i went poking about with the overloads

MMaxine so providing unsafe overloads seems excessive

AquaOP•8/4/23, 9:18 PM

not 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

AAqua not providing unsafe overloads causes problems though it will drive away users l...

Lyris the Kitori•8/4/23, 9:19 PM

it will be the same API, T*T* implicitly converts to Ptr<T>Ptr<T>

Maxine•8/4/23, 9:19 PM

yeah

Maxine•8/4/23, 9:19 PM

what beyley said

Lyris the Kitori•8/4/23, 9:19 PM

it will still be unsafe, just with some different names

Perksey•8/4/23, 9:19 PM

Kai•8/4/23, 9:19 PM

Wondering why. I get the usability question, but there's not really any concerns out of it being the wrong type?

yeah i have been moving towards nint, I wrote this code before I was aware that `IntPtr == nint`whic

Similar Threads

Similar Threads

Similar Threads