Knot 100% sure
P@grifon.petre how much bandwidth do you have atm
Pi want to nerdsnipe someone else into writing a competing solution to the overload problem
Pso that we have multiple prototypes to try out in a short timeframe
Mit don't work!
Khuh
Pyou need a TSelf
Kthat almost feels like a bug lol
Myeah its such a strange design decision
Kthe static abstracts can be called from the member type but also i guess those have a separate declaration on that type
Myeah
Mi wanted to use interfaces to reuse code
Mthat ain't happening now
Mif c# had templates this shit would be done in minutes
Pso the glass in my mind has been shattered a little bit
Pand... it's workable but it's making me realise just how ridiculous it is what we're doing
Pi still abstain that this is the only way without excessive overloads to achieve the level of flexibility we want
Pbut okay here it goes
Pthe Ptr type
Phow do you store one?
Plike in a class
Mnot meant to
Pbut
Pthen we have no safe storage medium
Myou store either a T* or a T[], and that gets cast to Ptr<T> implicitly
Pok but consider glfwCreateWindow
Pit returns a pointer
Mit should instead return some sort of handle to GLFWwindow
Mthat can be cast to ptr<T> as well
Pyeah that's where i'm at. making a
StoredPtr type (or add a Untracked variant of each type so you can just do PtrPtr<T>.Untracked)Pbut that's kinda crap
Pand you'd also have to assume that every return pointer is a stored pointer and not one we need to track
Pwhich is a reasonable assumption
MPtr<T> is meant to be an input type not an output type, because the return value of glfwCreateWindow will never be a T[]
Pbut it just feels meh
Min fact, you could just as well return T* directly
Pbut then we'd get all the unsafe whiners back on our case
Mi thought the point was not safety but the inconvenience of having to get a pointer to T[] to call a method that takes T*
Motherwise, the methods should be all T[] and never T*
Pour userbase generally feels more comfortable if they can pretend like the unsafe isn't happening even though it actually is
Pit is a puzzling phenomenon
Kthe point was to use implicit casts instead of thousands of overloads
Mwhat if we break their kneecaps
Pi guess the handle scenario needs to be resolved regardless if we want minimal unsafe in a codebase
Mshould GLFWwindow have methods on it?
Pno it's an opaque type
Pit may do eventually
Mwhat does the handle do, besides hiding the T*
Pas we do want to experiment with autogenerated OOP wrappers
P(or rather me and kai)
