? So what does AsPtr2D() return? that makes no sense to me
? So what does AsPtr2D() return? that makes no sense to me
PConstPtr<sbyte> incorrectly returns ConstPtr2D<sbyte> atm
Msbyte* to sbyte**, i presume
Pi.e. it converts a
ref this ConstPtr<sbyte> to a ConstPtr2D<sbyte>P(or in IL terms,
ldarg.0 ret)
Kah
Kref
KI see where the extra comes from now
Kimplicit ref
Plmao
Pi'm sorry I just found that hilarious
P
Ahmm that's where i disagree
one of the big benefits of C# is that it has overloads
sure you can have too many of them
but if you only have a few they can work very well
a pointer overload and an array overload
maybe a span
i just feel like this
i feel like for most users, they will only ever want safe overloads that take an array/whatever else, instead of a
and for those that want pointer overloads, they are available as well
one of the big benefits of C# is that it has overloads
sure you can have too many of them
but if you only have a few they can work very well
a pointer overload and an array overload
maybe a span
i just feel like this
Ptr<T> stuff may be a bit hard to understand, certainly i'm looking at this and wondering what exactly this is supposed to meani feel like for most users, they will only ever want safe overloads that take an array/whatever else, instead of a
Ptr<T> struct that may leave (especially to beginners) some users scratching their headsand for those that want pointer overloads, they are available as well
Kyeah so that way around I see no problem with my design? It would work fine, the same way it works now. Use some IL magic to load the arg ptr and then store it into the outer PtrType ref struct
K(but also do generic magic so the compiler knows what indirection level we are at now, but this isn't a runtime thing)
K(unfortunately the JIT won't see it that way and produce many re-compilations of the same IL but that's not on me)
K(and also also the case with The RefMutRef design)
Pcan you define an E2E of how it'll work with a dummy glfwGetError signature, sorry just being stupid and can't quite visualise it
Keeeh
Kcan you give me the E2E I'm supposed to translate? I don't know what it looks like right now 
Pwhat would
int glfwGetError(const char**) (i.e. sbyte**) look like, how would the user use it, and what does the AsPtr2D (or whatever) have to do to make it workMKint glfwError(ConstPtrType<Ptr<sbyte>>)
Kand that
Kjust ConstPtrType on the outside I think
Mi foind a problem
Pand presumably if I did
it'd pass?
it'd pass?
MPtrType<T> = contains a ref T
PtrType<Ptr<T>> = contains a ref Ptr<T> which contains a ref T, this is not allowed because Ptr is not a ref struct
PtrType<Ptr<T>> = contains a ref Ptr<T> which contains a ref T, this is not allowed because Ptr is not a ref struct
Mhow would PtrType work in this scenario
Pyeah I'm worried if we go this route we will accidentally make a GC hole
Psorry i do have a response to this I just keep getitng distracted
Mwe're having like 15 discussions at the same time 
KAsPtr2D I think turns
ref PtrType<sbyte> into PtrType<Ptr<sbyte>> (so I guess it should be AsConstPtr2D()) and the given ref is just stored as-is and the "the inner is also a ptr" is just tracked by the compiler via genericsKNo PtrType<Ptr<T>> just contaisn a ref byte, and so does PtrType<T>
Moh so the char** isn't a pointer to a variable?
Kwhen calling functions it just then re-calculates the inner ref
KI don't see how this is different from the
RefMut<sbyte> type at runtime? It's just a ref byte on the inside (or a readonly ref byte in this case, but same same)KIn neither case do we GC track the inner ref the outer one points to
K(which I don't think is necessary)
Mlike here's a C usage of glfwGetError to my understanding
Monly works if the method doesn't dereference the char*
Mwill work for GetError, yes
Pit is a GC hole today for jagged arrays, but I've worked around that in marshalling (see
SilkMarshal.JaggedArrayToPointerArray). if InteriorRef is actually a ref ConstPtr<int>, the referencee will continue to be tracked and ergo the encapsulated reference will continue to be trackedPthis would also be a GC hole if you could store a ConstPtr on the heap, but you can't as it's a ref struct
Kgreat
Kso then it's not a problem for
PtrType/ConstPtrType either given you can't put them on the heap eitherKprintf (or the C# equivalent) will dereference the char*. So it would be a problem, but perksey worked around it
Mmaybe this isn't a gc hole because being ref structs, since you need to hold the outer one somewhere to have the inner one, the outer one is never gonna go out of scope before the inner one
Mso kai's idea actually works
Pbut the main thing is
PtrType<Ptr<int>> the inner Ptr may reference a field on the heap, which presumably will be untracked when we go from PtrType<int> to Ptr<int> (or whatever we reinterpret it to)Kno Ptr is empty