hmm that's where i disagree one of the big benefits of C# is that it has overloads sure you can ha

hmm 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

Ptr<T>

Ptr<T>

Ptr<T>

Ptr<T> stuff may be a bit hard to understand, certainly i'm looking at this and wondering what exactly this is supposed to mean
i feel like for most users, they will only ever want safe overloads that take an array/whatever else, instead of a

Ptr<T>

Ptr<T>

Ptr<T>

Ptr<T> struct that may leave (especially to beginners) some users scratching their heads
and for those that want pointer overloads, they are available as well

Kai•8/4/23, 8:18 PM

yeah 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

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

(but also do generic magic so the compiler knows what indirection level we are at now, but this isn't a runtime thing)

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

(unfortunately the JIT won't see it that way and produce many re-compilations of the same IL but that's not on me)

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

(and also also the case with The RefMutRef design)

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

can you define an E2E of how it'll work with a dummy glfwGetError signature, sorry just being stupid and can't quite visualise it

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

eeeh

Kai•8/4/23, 8:20 PM

can you give me the E2E I'm supposed to translate? I don't know what it looks like right now

Perksey•8/4/23, 8:21 PM

what would int glfwGetError(const char**)int glfwGetError(const char**) (i.e. sbyte**sbyte**) look like, how would the user use it, and what does the AsPtr2D (or whatever) have to do to make it work

Maxine•8/4/23, 8:22 PM

PtrType<sbyte> a = ???;

PtrType<Ptr<sbyte>> b = a.PtrTo();

glfwGetError(b);

PtrType<sbyte> a = ???;

PtrType<Ptr<sbyte>> b = a.PtrTo();

glfwGetError(b);

Kai•8/4/23, 8:22 PM

int glfwError(ConstPtrType<Ptr<sbyte>>)int glfwError(ConstPtrType<Ptr<sbyte>>)

MMaxine ```cs PtrType<sbyte> a = ???; PtrType<Ptr<sbyte>> b = a.PtrTo(); glfwGetError(...

Kai•8/4/23, 8:22 PM

and that

Kai•8/4/23, 8:22 PM

just ConstPtrType on the outside I think

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

i foind a problem

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

and presumably if I did

PtrType<sbyte> a = nullptr;
PtrType<Ptr<sbyte> b = a.PtrTo();
glfwGetError(b);
Debug.Assert(a != nullptr);

PtrType<sbyte> a = nullptr;
PtrType<Ptr<sbyte> b = a.PtrTo();
glfwGetError(b);
Debug.Assert(a != nullptr);

it'd pass?

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

PtrType<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

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

how would PtrType work in this scenario

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

yeah I'm worried if we go this route we will accidentally make a GC hole

AAqua hmm that's where i disagree one of the big benefits of C# is that it *has* overl...

Perksey•8/4/23, 8:24 PM

sorry i do have a response to this I just keep getitng distracted

Maxine•8/4/23, 8:24 PM

we're having like 15 discussions at the same time

Kai•8/4/23, 8:24 PM

AsPtr2D I think turns ref PtrType<sbyte>ref PtrType<sbyte> into PtrType<Ptr<sbyte>>PtrType<Ptr<sbyte>> (so I guess it should be AsConstPtr2D()) and the given refref is just stored as-is and the "the inner is also a ptr" is just tracked by the compiler via generics

MMaxine PtrType<T> = contains a ref T PtrType<Ptr<T>> = contains a ref Ptr<T> which cont...

Kai•8/4/23, 8:24 PM

No PtrType<Ptr<T>> just contaisn a ref byte, and so does PtrType<T>

Maxine•8/4/23, 8:24 PM

oh so the char** isn't a pointer to a variable?

Kai•8/4/23, 8:24 PM

when calling functions it just then re-calculates the inner ref

PPerksey yeah I'm worried if we go this route we will accidentally make a GC hole

Kai•8/4/23, 8:25 PM

I don't see how this is different from the RefMut<sbyte>RefMut<sbyte> type at runtime? It's just a ref byteref byte on the inside (or a readonly ref byte in this case, but same same)

Kai•8/4/23, 8:25 PM

In neither case do we GC track the inner ref the outer one points to

Kai•8/4/23, 8:25 PM

(which I don't think is necessary)

Maxine•8/4/23, 8:26 PM

like here's a C usage of glfwGetError to my understanding

char* description = NULL;
if (glfwGetError(&description)) {
  printf(description);
}

char* description = NULL;
if (glfwGetError(&description)) {
  printf(description);
}

KKai In neither case do we GC track the inner ref the outer one points to

Maxine•8/4/23, 8:27 PM

only works if the method doesn't dereference the char*

Maxine•8/4/23, 8:27 PM

will work for GetError, yes

KKai I don't see how this is different from the `RefMut<sbyte>` type at runtime? It's...

Perksey•8/4/23, 8:27 PM

it is a GC hole today for jagged arrays, but I've worked around that in marshalling (see SilkMarshal.JaggedArrayToPointerArraySilkMarshal.JaggedArrayToPointerArray). if InteriorRefInteriorRef is actually a ref ConstPtr<int>ref ConstPtr<int>, the referencee will continue to be tracked and ergo the encapsulated reference will continue to be tracked

Perksey•8/4/23, 8:27 PM

this 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

Kai•8/4/23, 8:28 PM

great

Kai•8/4/23, 8:29 PM

so then it's not a problem for PtrTypePtrType/ConstPtrTypeConstPtrType either given you can't put them on the heap either

MMaxine will work for GetError, yes

Kai•8/4/23, 8:29 PM

printf (or the C# equivalent) will dereference the char*. So it would be a problem, but perksey worked around it

Maxine•8/4/23, 8:30 PM

maybe 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

Maxine•8/4/23, 8:30 PM

so kai's idea actually works

KKai so then it's not a problem for `PtrType`/`ConstPtrType` either given you can't p...

Perksey•8/4/23, 8:30 PM

but the main thing is PtrType<Ptr<int>>PtrType<Ptr<int>> the inner PtrPtr may reference a field on the heap, which presumably will be untracked when we go from PtrType<int>PtrType<int> to Ptr<int>Ptr<int> (or whatever we reinterpret it to)