Feedback on vector library

[petrihakkinen]

Late to the party, but may I suggest the following small but useful extensions to the vector library:

1. Add another constructor vector.create(x, y). This would be very useful when dealing with 2D coordinates. For example, applications could be 2D graphics and UI code. Z (and W) components would be filled with zero. Note that existing library functions already work out of the box for these use cases (dot, abs, min, max, floor, ceil, etc.).

2. For improved code ergonomics, add shortcuts for creating vectors using vector(x, y), vector(x, y, z) and vector(x, y, z, w). This would not require any syntactical changes to the language since this can be implemented using the __call metamethod (and configuring fastcall in compiler options).

[petrihakkinen]

Also, I noticed a small problem on the documentation page:
"vector.cross: ... Computes the cross product of two vectors. Ignores the fourth component in 4-wide mode and returns the 3-dimensional cross product."

It does not specify what will be the value of W in 4-wide mode (I'm guessing zero).

[aatxe]

Yeah, should be zero in the result (that's part of what is meant by it's "ignored"). We had some discussion about whether there even exists a natural notion of cross-product in four dimensions, and it seems like the answer is "not really" so we settled on this.

[petrihakkinen]

I thought "ignores" means that it does not use the W components of the inputs. I suggest the following clarification:
"Computes the cross product of two vectors. Ignores the fourth component in 4-wide mode and returns the 3-dimensional cross product. In 4-wide-mode the fourth component of the result is set to zero."

[aatxe]

I could definitely see an argument for including a 2d constructor, but doing so would need an RFC. The RFC also discussed the idea of adding a call metamethod for the vector constructors as you are in point 2, but we ultimately opted to not make a commitment to any particular shorthand constructor yet since it was blocking progress on the RFC altogether. I think we could definitely put a separate RFC for, pretty much, "vector construction improvements" at this point.

[petrihakkinen]

Cool, I can start working on the RFCs.

[petrihakkinen]

One additional issue came up that is somewhat related to the vector library, but is more generic. We are not yet sure if we want to adopt the vector library. We have our own which is very widely used in our codebase and has a different set of functions. It is also possible that we only adopt the vector library partially and retain some of our API.

The problem is that Luau does not really allow patching built-in libraries like Lua because of built-ins being hardcoded in the compiler. We can remove, rename or overwrite any of the built-ins by simply modifying the module table (from C code before loading any scripts), but all those functions still exists as built-in fastcalls which have priority.

Would it make sense to have some control over built-ins? I'm thinking one way to do this would be adding a new field disabledBuiltIns to CompileOptions.

[vegorov-rbx]

I think it makes sense to have some way of disabling built-ins.

[petrihakkinen]

I've created an issue for this here:
#1538

[petrihakkinen]

I've created PRs for two RFCs here:

2-component vector constructor:
luau-lang/rfcs#74

Shorter vector constructor:
luau-lang/rfcs#75