Add a Workspace Property to Return Luau Vectors From Instance Properties

Feature Requests Engine Features
,
1

Feature Request

I would like to propose a Workspace property that allows supported Vector3 Instance properties to return Luau’s native vector datatype instead of Vector3.

Proposed property:

Workspace.InstancesUseVector

When enabled, reading a supported Instance property that normally returns a Vector3 would return a Luau vector instead.

For example:

local Position = Part.Position

would normally produce a Vector3, but with:

Workspace.InstancesUseVector = true

it would produce a Luau vector.

Why This Is Useful

Luau’s native vector datatype is designed for efficient vector operations and is particularly useful for performance-sensitive code.

However, Instance properties still commonly return Vector3.

This means a system that wants to consistently use Luau vectors can be forced to convert values immediately after reading them from Instances.

For example:

local Position = Part.Position

Position = vector.create(
	Position.X,
	Position.Y,
	Position.Z
)

The conversion itself is unnecessary if the developer already intends to perform the computation using Luau vectors.

With the proposed property:

Workspace.InstancesUseVector = true

local Position = Part.Position

Position would already be a Luau vector.

The data can therefore remain in the native Luau vector representation as it moves from the engine into Luau code.

Opt-In For Compatibility

The default behavior should remain unchanged:

Workspace.InstancesUseVector = false

Existing experiences would therefore continue receiving Vector3 values.

Developers who want Instance properties to return native Luau vectors could explicitly enable the behavior.

This makes the feature backwards-compatible while giving performance-sensitive experiences a way to opt into the more appropriate datatype.

No Conversion API Required

I would also prefer this to happen directly at the Instance property boundary rather than requiring developers to manually convert every returned value.

For example, without this feature:

local Position = Part.Position
local Direction = vector.create(
	Position.X,
	Position.Y,
	Position.Z
)

With this feature:

local Direction = Part.Position

The latter is both simpler and avoids requiring every developer to repeatedly perform the same conversion.

Proposed API

Workspace.InstancesUseVector: boolean

Default:

false

Behavior:

-- Default
local Position = Part.Position -- Vector3

-- With InstancesUseVector enabled
local Position = Part.Position -- vector

This would provide a simple opt-in mechanism for keeping vector data in Luau’s native representation when reading it from Instances, eliminating unnecessary conversion work in vector-heavy systems while preserving existing behavior by default.

2 Likes
2

how should typeof act with this property enabled?

to clarify, the type function already returns "vector" if a Vector3 is passed into it. if you didnt know somehow. so your proposed property would probably be something within the type checker rather than anything else

1 Like
3

if you compare typeof vector to typeof vector3, it returns true

4

the typecheck should adjust to that and hint that its a vector obviously
this should not be a problem to implement

5 
type(vector.create(1,2,3)) -- -> vector
type(Vector3.new(1,2,3)) -- -> vector

typeof(vector.create(1,2,3)) -- -> Vector3
typeof(Vector3.new(1,2,3)) -- -> Vector3
6

many people use typeof()

if they write typeof(part.Position) with the workspace property enabled, they might expect it to return "vector" instead of "Vector3"

1 Like
7

that a really weird behavior actually
Pretty sure it meight be a VM bug of sort
idk how vm roblox uses behaves so internally it may have both of them as sort of a unified type tag
If its internally is the same then this change should be purely visual for typecheck

8

considering there is a toggle for enabling / disabling loadstring in ServerScriptService, i doubt it would be impossible to make typeof return “vector” instead of “Vector3” when this toggle is enabled.

1 Like
9

The irony. From the range of developers I (and not necessarily personally) know, almost none of them use the vector datatype.

10

you can do vector.magnitude(Vector3.one) and it will work normally but it will type error. there isnt anything stopping you from using the vector library with vector3s other than type errors.

11

That derailing the topic now
also there is quite literally no irony here
I make a proposal to use Luau datatype instead of userdata
The consistency here is like in a concrete i don’t understand your logic

12

The problem is that there will be problems with native code compilations (and compilation in general)
Vector3 and vector is just not the same thing at all
For interpreter maybe pretty much the same
for compiler its categorically not

13

Vector3 does not use userdata.
image

14

As i said its for runtime
its not for compiler
Compiler still will act as if its a userdata
Vector3 just wont be interpreted same way as vector for the compiler
That what im trying to say

15

Hi there, thanks for the suggestion, but I believe there is a misunderstanding of how vector and Vector3 work here that is leading to your suggestion.

The Vector3 type in Roblox is the exact same primitive value that Luau offers as a native vector datatype. There are no efficiency differences between them, and no conversion necessary. Luau affords a mechanism for embedders to set the metatable of vector to support a library extension to them, and Roblox uses exactly that feature for all vectors to provide them the Vector3 API surface that Roblox had before Luau’s primitive vectors ever existed. You can see this if you look at the result of typeof(vector.create(1, 2, 3)) in Roblox.

There is a separate problem that is probably leading to this confusion though: the implementation of the vector type in Luau’s type system was set up in a way that makes it disjoint from the Vector3 type. This does not reflect any runtime difference whatsoever, and I’d recommend just using casts between the two types to work around this problem, rather than the “conversions” you described like vector.create with the components of an already-existing Vector3. This problem should eventually be fixed in the type system at some point in the future, but it hasn’t been prioritized to this point.

2 Likes
16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.