[API Proposoal]: Additional methods for "DotNext.Span"

[CodingMadness]

Heyo,

I have written some "SpanExtension" methods cause its needed to be optimized for rendering logic and I thought maybe they could go inside your DotNext.Span namespace :)

I will post a github gist "Utils" class where i hord those functions needed for my 2D game.

This gist contains 3 core methods:

• span.MoveBy(Range, int) ---------> moves a specified range within the span by a value in either LEFT or RIGHT direction
  0 > value = left direction;
  0 < value = rigth direction;

• span.Move2(Range, int) ---------> moves a specified range within the span to a specific index

• span.Swap(this ROS self, ROS x, ROS y); ---------> swaps 2 slices from the same span
  without extra heapbased copies.

The other 2 methods are just, 1 for simple (not fully fledged tests, did not have time for it yet..) and the other is just a direct wrapping function of Swap(...) to work easier with ROS-types.

this gist here contains the "SpanInfo" type building all the nessecary information pre-hand, so its easier to control what is needed and when to cuse them, debloats heavily the Swap() function

I really hope that you have a look upon them and tell me if they are useful and when not, also tell me pls why ^^

All good 2 you and ur family and really really nice job you did with DotNext!

Cheers!

[sakno]

ReadOnlySpan<T> cannot be modified in general. Unsafe operation doesn't help here because it can represent truly read-only memory segment which leads to SEGFAULT. For instance,

static ReadOnlySpan<byte> Buf => new byte[] {1, 2};

returns a pointer to read-only DATA segment within PE/ELF file. IL bytecode for it:

.data cil I_00002868 = bytearray (
        01 02
    )

[sakno]

Move2 can be replaced with

Span<T> span;
span[x..y].CopyTo(span.Slice(start));

Of course, it requires more checks because span[x..y].Length can be greater than span.Slice(start). But anyway, it's just a single line of code.

[sakno]

I think Swap might have the following signature:

public static Swap<T>(this Span<T> span, Range range1, Range range2);

Swap of two values requires third temporary storage. The same is applicable to Span<T>. Thus, it cannot be done without heap allocation for some use cases. For instance, if a range is greater than the available stack memory, the data must be placed onto the heap.

[CodingMadness]

Move2 can be replaced with

Span<T> span;
span[x..y].CopyTo(span.Slice(start));

Of course, it requires more checks because span[x..y].Length can be greater than span.Slice(start). But anyway, it's just a single line of code.

I mean, if you have 1 line of code or 3 doesnt really matter, no?

[sakno]

I mean that Move2 is too simple (trivial) to be an extension method.

[CodingMadness]

I think Swap might have the following signature:

public static Swap<T>(this Span<T> span, Range range1, Range range2);

This is valid, but also sometimes you dont have the range at hand and just the slices itself, I think an overload can be useful.

ReadOnlySpan<T> cannot be modified in general. Unsafe operation doesn't help here because it can represent truly read-only memory segment which leads to SEGFAULT. For instance,

static ReadOnlySpan<byte> Buf => new byte[] {1, 2};

returns a pointer to read-only DATA segment within PE/ELF file. IL bytecode for it:

.data cil I_00002868 = bytearray (
        01 02
    )

I mean, ofc you need to know WHEN you use such code, I am and noone else who aallows such thing is to be kept responsible for the devs action, OF course you dont use that stuff when u are worried about the readonly stuff, I for me as an example, am creating certain structs out of a string which has some key informations and changing that private string is not a problem cause noone outside has sight to it anyway, but its very useful rather than doing mass copy of such a string (4KB) in a loop (cause its a gameloop which renderes certain gameobjects out of that struct which has to be created efficiently out of the string.)

EDIT: Just because we use C# doesnt mean that unsafe-operations (in a nicer and cleaner way than C/C++) should be abandoned, you will have always to know what you are doing, I mean just by your Intrinsics class i could modify data of some internals of other structs but why should I do that? But having the chance to do so if NEED BE, is awesome.

[CodingMadness]

I mean that Move2 is too simple (trivial) to be an extension method.

I see what you mean, (despite me forgetting to clear the moving part to emulate a true move) its also symantically stronger, when you can just have a range and it shall be "moved" somewhere else, but okay thats up 2 you in this case.

[sakno]

you will have always to know what you are doing,

Exactly. It must be explicit. Therefore, Span<T> is a better choice because you modifying contents of the memory block. If you want to operate on ReadOnlySpan<T> just convert it to Span<T> using MemoryMarshal.CreateSpan manually to highlight unsafe aspect of your conversion.

but also sometimes you dont have the range at hand

Why? Instantiation of Range is very cheap, it is value type. And it is more readable to the user. If you have slices of the original span then you know the ranges.

[sakno]

scoped Span<T> lastCopy = stackalloc T[last.Length]; this can cause StackOverflowException

[CodingMadness]

Exactly. It must be explicit. Therefore, Span<T> is a better choice because you modifying contents of the memory block. If you want to operate on ReadOnlySpan<T> just convert it to Span<T> using MemoryMarshal.CreateSpan manually to highlight unsafe aspect of your conversion.

Actually I am already doing internally: "ROS.AsWriteable()" to make a Span out of ReadOnlySpan, but you suggest to let the user itself do that and not to take that task from him? Okay, I can agree to that.

scoped Span<T> lastCopy = stackalloc T[last.Length]; this can cause StackOverflowException

Tbh, in absolute theory yes, but when you look at such a function, Idk if like copying (* AT MAXIMUM*) 256 chars is that big of a deal, so the x and y together should never be more than 1KB in total or so, thats why i didnt do any check for them and wanted to let the user know it by the pure XML comment to not do to big slices but I could improve that part by your "BufferPooling" types in DotNext to be absolutely sure when its to huge to use your buffer.

[sakno]

Tbh, in absolute theory yes

Public method should work in any circumstances and with any corner cases.

together should never be more than 1KB

Even in that case it may cause stack overflow.

[CodingMadness]

Tbh, in absolute theory yes

Public method should work in any circumstances and with any corner cases.

together should never be more than 1KB

Even in that case it may cause stack overflow.

okay got it, i will improve that by using BufferWriterSlim<T> I think its a good fit to just extend the size if need be.

[CodingMadness]

MemoryMarshal.CreateSpan is used by an internal function in the "Utils" class which is called AsWriteAble() to make that call easier cause it was abit annoying.

  public static Span<T> AsWriteable<T>(this ReadOnlySpan<T> readOnlySpan) =>
        MemoryMarshal.CreateSpan(ref Unsafe.AsRef(readOnlySpan[0]), readOnlySpan.Length);```

[CodingMadness]

you will have always to know what you are doing,

Exactly. It must be explicit. Therefore, Span<T> is a better choice because you modifying contents of the memory block. If you want to operate on ReadOnlySpan<T> just convert it to Span<T> using MemoryMarshal.CreateSpan manually to highlight unsafe aspect of your conversion.

but also sometimes you dont have the range at hand

Why? Instantiation of Range is very cheap, it is value type. And it is more readable to the user. If you have slices of the original span then you know the ranges.

As I said, i can offer both, overload with range x,y and ROS x,y because its not so easy to get a range out of a slice, because when u have the slices, why u just dont swap directly, why u want to create an extra range from it, on the other hand, sometimes u have (start, length) and can use that rather than to slice it and then pass the slice, so offering both is better, because keep in mind, sometimes, you get a Slice back from a function, so why would u want to get a range from there (which is 2 lines of code and again and .IndexOf(slice)) where as you can just directly put it, offering both is the solution.