diff --git a/TEMPLATE.md b/TEMPLATE.md index 266922b..52fc95f 100644 --- a/TEMPLATE.md +++ b/TEMPLATE.md @@ -1,21 +1,44 @@ -# Feature name +# buffer.swap(b: buffer, x: number, y: number, range: number?) ## Summary -One paragraph explanation of the feature. +`buffer.swap(b, x, y, range?)` swaps a variable `range(?=1)` of bytes stored at offsets `x` and `y` of buffer `b` ## Motivation -Why are we doing this? What use cases does it support? What is the expected outcome? +The absence of a byte-range-swap function implies that for any variable range of bytes that need to be swapped, these bytes would have to be normalized as strings (see *Design*), *then* written back into the buffer. Although the implementation works, it would make more sense to have a buffer function that interally manipulates the desired offsets/range of bytes instead of the provided method where the byte ranges are interpreted as strings to achieve the same result + +In short, the current swap implementation has a string "layer" (unneccessary complexity/operations/conversions? (conjecture)), whereas the proposal for `buffer.swap( ... )` internally manipulates the byte ranges without any string interpretations etc. ## Design -This is the bulk of the proposal. Explain the design in enough detail for somebody familiar with the language to understand, and include examples of how the feature is used. +An example of a `buffer.swap( ... )` implementation for any `range` range of bytes: + +```lua +--- swaps range of bytes stored at offsets `x` and `y` \ +--- `range (?=1)` range of bytes to swap +local function swap(b: buffer, x: number, y: number, range: number?) + local z = buffer.readstring(b, x, range or 1) + buffer.writestring(b, x, buffer.readstring(b, y, range or 1)) + buffer.writestring(b, y, z) +end + +local b = buffer.create(8) --- create 8-width buffer +buffer.writef32(b, 0, math.pi) --- store 3.14... at 0 +buffer.writef32(b, 4, 2*math.pi) --- store 6.28... at 4 + +swap(b, 0, 4, 4) --- buffer.swap(b, 0, 4, 4) + +print(buffer.readf32(b, 0)) --- 6.28... is now at 0 +print(buffer.readf32(b, 4)) --- 3.14... is now at 4 +``` ## Drawbacks -Why should we *not* do this? +Real use-cases may be sparse, where this rfc could be interpreted as having added bloat to the buffer library ## Alternatives -What other designs have been considered? What is the impact of not doing this? +`is:pr is:open buffer.swap` search query on `/luau-lang/rfcs/pulls` returns no results + +`buffer.swap[u/i/f/string/...][8/16/32/64/...](b, x, y, range?)` (a case for each buffer type) was initially considered but that would very quickly become a nightmare for managing code. The provided working implementation is shown because (despite normalizing bytes as strings) it most-closely represents the goal of this rfc