luau-lang/rfcs
1
0
Fork 0
mirror of https://github.com/luau-lang/rfcs.git synced 2025-04-20 03:44:05 +01:00
Code Issues Projects Releases Packages Wiki Activity

corrections to function types + special syntax

Browse source
This commit is contained in:
ffrostfall 2024-05-05 13:56:14 -04:00
parent 54c5b19a66
commit 62c86b4a22
1 changed files with 5 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docs/vector-library.md
View file

@ -24,7 +24,7 @@ Creates a vector with 3 components: x, y, z. If the feature flag for wide vector
Due to the common usage of vectors, vector creation should be ergonomic. Therefore, it is probably worth breaking the `create()` naming standard. Due to the common usage of vectors, vector creation should be ergonomic. Therefore, it is probably worth breaking the `create()` naming standard.
`vector.magnitude(vecA: vector): vector` `vector.magnitude(vecA: vector): number`
Calculates the magnitude of a given vector. Calculates the magnitude of a given vector.
@ -36,9 +36,9 @@ Returns the unit vector (aka normalized vector) of a given vector.
Returns the cross product of two vectors. Returns the cross product of two vectors.
`vector.dot(vecA: vector): vector` `vector.dot(vecA: vector, vecB: vector): vector`
Returns the dot product of a vector. Returns the dot product of two vectors.
--- ---
@ -70,4 +70,6 @@ Do nothing; vectors have an internal constructor, which lets the runtime impleme
A more standard alternative to `vector(...)` could be something like `vector.create` or `vector.new`. This follows the standard set by `buffer.create`, `coroutine.create`, and `table.create`, and doesn't involve calling a table. A more standard alternative to `vector(...)` could be something like `vector.create` or `vector.new`. This follows the standard set by `buffer.create`, `coroutine.create`, and `table.create`, and doesn't involve calling a table.
Another alternative to vector creation is special syntax for creating buffers, such as `<x, y, z>`. This would require a lot more complexity & discussion, however it would fall more in line with the other primitive types.
Instead of `vector.magnitude`, the magnitude could be derived from the vector's coordinates themselves, and be accessed by a property instead of a function. There is a downside to this: all current properties of vectors are hard-coded to the VM, so any new property to vectors requires a lot of additional complexity & changes to the VM to allow for this. A library function, however, would be trivial. An easy and quick workaround to the verbosity would be at the runtime/C API level. It's trivial to set the metatable of vectors to be the vector library: this allows for `vec:magnitude()` without much issue. Instead of `vector.magnitude`, the magnitude could be derived from the vector's coordinates themselves, and be accessed by a property instead of a function. There is a downside to this: all current properties of vectors are hard-coded to the VM, so any new property to vectors requires a lot of additional complexity & changes to the VM to allow for this. A library function, however, would be trivial. An easy and quick workaround to the verbosity would be at the runtime/C API level. It's trivial to set the metatable of vectors to be the vector library: this allows for `vec:magnitude()` without much issue.