if you can implement all the requirements using this style we would welcome it with open arms, but I

if you can implement all the requirements using this style we would welcome it with open arms, but I think we concluded previously that it wasn’t possible team-talk

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

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

PerkseyOP•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

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

you’d have to force users to use fixed

PerkseyOP•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 ...

PerkseyOP•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.

khitiara•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.

PerkseyOP•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.

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

span used to use a compiler-substituted primitive struct called ByReference<T>ByReference<T> which was internal

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

yeah I know that

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

just providing context in case others dont

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

i dont believe that can be replicated nowadays though

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

it can, it’s called a ref field

PerkseyOP•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

khitiara•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...

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

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

khitiara•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

PerkseyOP•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

PerkseyOP•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?

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

that would be the sentinel

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

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

PerkseyOP•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

PerkseyOP•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

PerkseyOP•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

if you can implement all the requirements using this style we would welcome it with open arms, but I

Similar Threads