yeah this loses the ref safety from ref structs in exchange for allowing the syntax we wanted in the

yeah this loses the ref safety from ref structs in exchange for allowing the syntax we wanted in the first place without the limits on using them as ref fields

Volte•10/20/23, 2:00 AM

shrimpcat#0000

otherwise how do you differentiate Get on PtrType<T> vs Get on PtrType<Ptr<T>>

Original Message

Click here

Quoted by perksey#0000

PPerksey if you can implement all the requirements using this style we would welcome it w...

Maxine•10/20/23, 2:00 AM

i can't even remember what i meant

Maxine•10/20/23, 2:01 AM

actually

Maxine•10/20/23, 2:01 AM

that was a problem with that design

Maxine•10/20/23, 2:01 AM

this design is ref-less

Maxine•10/20/23, 2:01 AM

shouldn't be a problem

Kkhitiara yeah this loses the ref safety from ref structs in exchange for allowing the syn...

Maxine•10/20/23, 2:02 AM

hm.

Maxine•10/20/23, 2:02 AM

we could just live with that

Maxine•10/20/23, 2:02 AM

what was the benefit of using the Ptr wrapper over T* again

Maxine•10/20/23, 2:03 AM

was it specifically for ref safety

MMaxine this design is ref-less

Perksey•10/20/23, 2:03 AM

but

PPerksey but

Maxine•10/20/23, 2:03 AM

right yeah

Maxine•10/20/23, 2:03 AM

that was the thing i was thinking

Maxine•10/20/23, 2:03 AM

but if you can only make a Ptr to unmanaged types

Perksey•10/20/23, 2:03 AM

you’d have to force users to use fixed

Perksey•10/20/23, 2:04 AM

and at that point just use raw pointers

Maxine•10/20/23, 2:04 AM

hm.

Maxine•10/20/23, 2:04 AM

yeah

Maxine•10/20/23, 2:04 AM

i see it

Maxine•10/20/23, 2:04 AM

and we can't do the thing that Span<T> did before ref fields, because that also had problems, i imagine

Curin•10/20/23, 2:04 AM

The main purpose for this was to handle slimming our overrides down.

MMaxine and we can't do the thing that Span<T> did before ref fields, because that also ...

Perksey•10/20/23, 2:05 AM

that was essentially a ref field before the language caught up

CCurin The main purpose for this was to handle slimming our overrides down.

Maxine•10/20/23, 2:05 AM

a wrapper that can handle both pointers and arrays

Curin•10/20/23, 2:06 AM

If 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.

khitiaraOP•10/20/23, 2:06 AM

what span did before ref fields was an intrinsic that behaved like a ref field that got substituted out by the runtime

CCurin If we wanted to avoid making users use fixed, we could have a constructor that w...

Maxine•10/20/23, 2:06 AM

bad idea

Curin•10/20/23, 2:07 AM

yeah not my favorite idea, but it would avoid the need for fixed statements.

Perksey•10/20/23, 2:08 AM

you 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

Curin•10/20/23, 2:09 AM

okay so the major problem is how do we consume span<T>, array[][], string[], etc. preferably implicitly.

khitiaraOP•10/20/23, 2:09 AM

span used to use a compiler-substituted primitive struct called

ByReference<T>

ByReference<T>

which was internal

Perksey•10/20/23, 2:09 AM

yeah I know that

khitiaraOP•10/20/23, 2:09 AM

just providing context in case others dont

khitiaraOP•10/20/23, 2:10 AM

i dont believe that can be replicated nowadays though

Perksey•10/20/23, 2:10 AM

it can, it’s called a ref field

Perksey•10/20/23, 2:10 AM

but before fast span was a thing you couldn’t create a heap ref without providing the owning object

khitiaraOP•10/20/23, 2:10 AM

well yeah

PPerksey but before fast span was a thing you couldn’t create a heap ref without providin...

Perksey•10/20/23, 2:10 AM

this was what DangerousCreate did, and was removed as soon as humanly possible

khitiaraOP•10/20/23, 2:10 AM

my point was more you cant use the sneaky way to circumvent this ref field to ref struct issue

Perksey•10/20/23, 2:11 AM

yeah sure

PPerksey this was what DangerousCreate did, and was removed as soon as humanly possible

Maxine•10/20/23, 2:12 AM

what if

Perksey•10/20/23, 2:12 AM

I also don’t know any way that doesn’t involve fixed, refs, or sentinels to track a heap pointer

Maxine•10/20/23, 2:13 AM

weak table?

Perksey•10/20/23, 2:13 AM

that would be the sentinel

Perksey•10/20/23, 2:13 AM

and you’d have to have a secondary object to act as the sentinel

Perksey•10/20/23, 2:14 AM

because 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

Perksey•10/20/23, 2:14 AM

you can’t have an object manage its own lifetime in a managed to native transition without fixed or refs

Perksey•10/20/23, 2:15 AM

technically we could make it so the user can opt into manually managing their heap memory, but that sucks

Maxine•10/20/23, 2:15 AM

call into internal coreclr methods

Maxine•10/20/23, 2:16 AM

there must be one of them

Curin•10/20/23, 2:22 AM

Here'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?

yeah this loses the ref safety from ref structs in exchange for allowing the syntax we wanted in the

Similar Threads