yeah this is great that we talk about this tbh
yeah this is great that we talk about this tbh
Kso the concern that we have had a few times when talking about this is that for functions like the one I gave above, it's really unclear to us which overloads to expose
Poh yeah sure, but all i'm saying there's a reason we moved away from the rigid 1.0 structure primarily because we got complaints about the overloads kinda being naff to use
Kand exposing all of them is problematic because then you get no intellisense and maybe your IDE just dies
Kwhich... yeah that's super bad
Pfor sure, this is also why we refused to include overloads in the original 3.0 proposals haha
Kf(int***, void**, uint**, res*, float**)here there is a very good argument that we should support passing
T[] in place of T* everywhere, I think everyone agrees?f(int**[], void*[], uint*[], res[], float*[]) should be a valid way to pass the args
Mimplicit casts to ptr might genuinely be a good alternative to having every permutation of argument as an overload
Mbut also doesn't work for every possible case
Kbut then what about
these seem fine?
f(int*[][], void[][], uint[][], res[], float[][]) (now next to void[][] not being valid, so it should stay void*[])these seem fine?
Li feel like this is also an IDE problem
Lintellisense should pick up on implicit casts and give you nice completions
AI'm not familliar with 1.0 so I can only say it from my own thoughts
one way to do it could be to simply stick to the spec, and don't provide any helpers etc
raw pointer overloads just have the exact same signature as the C API
and the safe overloads are similar, just any time there is a
or something along those lines
in this way, you only need 2 or 3 overloads (if you include spans)
one way to do it could be to simply stick to the spec, and don't provide any helpers etc
raw pointer overloads just have the exact same signature as the C API
and the safe overloads are similar, just any time there is a
lengthor something along those lines
in this way, you only need 2 or 3 overloads (if you include spans)
Know we want to pass different versions of this to different args, so you take those 3 permutations I've shown and get 15 overloads (5 * 3 versions = 15) (minus the one void*[] that's not valid = 12 overloads)
KThis is true, but very much not ergonomic. C APIs will most likely not have a length or have a shared length for several of the arguments. It's hard to figure out what's what and even harder to really put this in an API
Lwhile i agree with the "its less visually obvious to newcomers", once you learn the way its structured its a lot better ergonomically, its just teaching people that way, we'd need excellent documentation for this to really be viable
Kand it also doesn't really offer a good solution for passing
int*[][] or int*[,]Ptbh i'm content with having a wrapped overload and an unwrapped overload i.e. if you used only the unwrapped functions, Silk.NET is literally just TerraFX but with pretty names.
Aif it's anything, these are the overloads I provide for creating a buffer in pie
https://github.com/piegfx/Pie/blob/main/src/Pie/GraphicsDevice.cs#L83-L122
they are not perfect and could do with a little refining, but they encompass pretty much everything one may want to do with them
the unsafe overload is there for those who want it, and there are safe options as well
https://github.com/piegfx/Pie/blob/main/src/Pie/GraphicsDevice.cs#L83-L122
they are not perfect and could do with a little refining, but they encompass pretty much everything one may want to do with them
the unsafe overload is there for those who want it, and there are safe options as well
Myeah fuck it why not
Kthis I would prefer personally
Lyeah if your methods have a lot of thing* and you do array overloading you start getting to 3**11 overload territory
Ayeah, that could work quite well
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?"