and we can't do the thing that Span<T> did before ref fields, because that also had problems, i imag
and 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
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
Pbasically what’s in Playground
Tdid I get pinged?
discord said there was one here, but nothing in the inbox or that I can find
discord said there was one here, but nothing in the inbox or that I can find
Pyeah, I pinged you a while ago wrt porting silk.net.maths to generic maths. One sec
Vperksey#0000
@266043404398493696 i don't suppose over the years you've come up with some smart ideas for Vector2<T>? we're looking into moving to generic maths, and obviously there's loads of cases that Silk.NET supports today that would be silly in a generic maths world (e.g. you can do
we can go with use case parity with 2.X, even if it doesn't make sense, but i figured given you'll have to be tackling this problem eventually maybe you have some loose thoughts knocking about in that noggin.
Sin on a byte).we can go with use case parity with 2.X, even if it doesn't make sense, but i figured given you'll have to be tackling this problem eventually maybe you have some loose thoughts knocking about in that noggin.
Original Message
Quoted by perksey#0000
TI see, I see. I wonder why it only showed me the ping today 
TVector2<T> supporting only floating-point vs supporting integers in general is something I've struggled with finding the right balance for/aroundTWhen you consider some of the most core APIs that a "euclidean vector" needs to provide
then, in general, there are a lot of concepts that simply don't work with integer types
for example, you really can't even do something as basic as normalize the vector or get a valid length
but you can still do some things that somewhat make sense, such as get a rounded distance
then, in general, there are a lot of concepts that simply don't work with integer types
for example, you really can't even do something as basic as normalize the vector or get a valid length
but you can still do some things that somewhat make sense, such as get a rounded distance
Tnow, you could argue that at the most basic level, it is fine for
which is to say, it does the computation and rounds it to the nearest representable result using some specified rounding direction
but, this gets problematic when needing to consider the algorithm generically and version it over time
because while you could give an approximation of
you can't do the same with integers and things trend towards 0 or 1 for all answers
Sin(x) for an integer to work much as x / y doeswhich is to say, it does the computation and rounds it to the nearest representable result using some specified rounding direction
but, this gets problematic when needing to consider the algorithm generically and version it over time
because while you could give an approximation of
Sin(x) for floating-point, as you can say that Pi can be loosely representedyou can't do the same with integers and things trend towards 0 or 1 for all answers