Mshouldn't be a problem
Mhm.
Mwe could just live with that
Mwhat was the benefit of using the Ptr wrapper over T* again
Mwas it specifically for ref safety
Pbut
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> which was internalPyeah 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