Pthere was a function in D2D1 with 16 pointer parameters
Roh dear god
Pgenerated 2(2^16) overloads
Roh god
Sspeaking of pointers and unsafe code,do you plan on adding a way to use safe code while creating buffer objects?
A
that is actually hilariousRthat makes ASSIMP look sane
Pthere's already a way
Pbut again the visibility is terrible
Ruse safe overloads
Sthen why is it not in the docs?
Sor examples to be more precise
Pbecause it's not the best use of silk maintainer time right now
Pmaintainer time is best spent on actually developing the library right now
L^
RIMHO there should be 2 overloads for Silk.Net 3.0 per existing overload
Ra safe and unsafe version
AI could work on the docs 
AI keep meaning to sorry
AJust lazy
Syou know,i would actually love to doc silk.net if i actually knew what 99% of the functions actually did
Ruse intellisense :P, oh wait, intellisense can actually crash your IDE when talking 12000 overloads
ASo have 24000 overloads for that one function now?
ANeeds more
Rno
Pftr we don't expect anyone to document the generated functions
R2 overloads per function (with the original function overloads)
AAh
Right
Right
RFully safe, fully unsafe no more
Rthe question is how should the safe stuff look
Rlike you could have multiple "safe" overloads
Rwhich should you generate
AOnly thing we need now is
Etc
Etc
AI screwed that up
Pwell that's why i was thinking of the
PointerLikeone parameter type that multiple types implicitly convert to
Pthe main issue i can already see is ref lifetime though and implicit ref conversions
Rhmm
Rinteresting
Pactually ref lifetimes would be easy
Pbut the implicit conversion of a ref to a type is i think impossible
Pso it'd have to be
new(ref x) instead of ref xALifetimes? I thought that was only a rust thing
Rmost certainly not
Prust is just the thing that makes lifetimes explicit
Pyou have implicit lifetimes in C#
Pyou also have scary things called "GC holes" as well
Rit is a thing in all languages, some do better at hiding it
AI see
RRAII for instance in C++