Mthat was the thing i was thinking
Mbut if you can only make a Ptr to unmanaged types
Pyou’d have to force users to use fixed
Pand at that point just use raw pointers
Mhm.
Myeah
Mi see it
Mand we can't do the thing that Span<T> did before ref fields, because that also had problems, i imagine
CThe main purpose for this was to handle slimming our overrides down.
Pthat was essentially a ref field before the language caught up
Ma wrapper that can handle both pointers and arrays
CIf we wanted to avoid making users use fixed, we could have a constructor that would allow them to allocate unmanaged memory, and then dispose it. behind the scenes.
Kwhat span did before ref fields was an intrinsic that behaved like a ref field that got substituted out by the runtime
Mbad idea
Cyeah not my favorite idea, but it would avoid the need for fixed statements.
Pyou can technically achieve what Span.DangerousCreate did before it was removed by calculating the ref offset from its owning object, creating a GCHandle to the object that owns the ref, and then reapplying that offset
Cokay so the major problem is how do we consume span<T>, array[][], string[], etc. preferably implicitly.
Kspan used to use a compiler-substituted primitive struct called
ByReference<T>yeah I know that
Kjust providing context in case others dont
Ki dont believe that can be replicated nowadays though
Pit can, it’s called a ref field
Pbut before fast span was a thing you couldn’t create a heap ref without providing the owning object
Kwell yeah
Pthis was what DangerousCreate did, and was removed as soon as humanly possible
Kmy point was more you cant use the sneaky way to circumvent this ref field to ref struct issue
Pyeah sure
Mwhat if
PI also don’t know any way that doesn’t involve fixed, refs, or sentinels to track a heap pointer
Mweak table?
Pthat would be the sentinel
Pand you’d have to have a secondary object to act as the sentinel
Pbecause if you create a single CWT (aka DependentHandle) with a sentinel freeing the GCHandle upon collection and you use the GCHandle target as the sentinel itself, it’ll never get collected
Pyou can’t have an object manage its own lifetime in a managed to native transition without fixed or refs
Ptechnically we could make it so the user can opt into manually managing their heap memory, but that sucks
Mcall into internal coreclr methods
Mthere must be one of them
CHere's a question, currently the SilkX code uses Unsafe.AsPointer to cast a ref variable to a related pointer. What happens if the GC moves the value between us getting the pointer and using it in native code?
Does Unsafe.AsPointer fix the object so the GC can't move it?
Does Unsafe.AsPointer fix the object so the GC can't move it?
Pnope, that’s why I wanted to make sure that you made the operators that use Unsafe.AsPointer explicit instead of implicit
Pbecause it’s basically only safe for stack refs
Por struct this refs
Palthough even that can be unsafe
Pbasically only use it if you know it ain’t moving
Cso in practice is this usable to take my vertex array or descriptor table data and pass it into commandlists? Data most likely put on the heap.
Pthe current implementation is yeah as you won’t have Unsafe.AsPointer in the loop
Pthe ref will remain tracked until it’s fixed by the generated code
CIs the plan for users to use these objects in place of an array or object all the time or just to be silently converted to when you pass in an object into a Silk function?
Pit’s only intended to be an interchange type
Pso when you need to pass something to native or read something from native