[2.0] Add array, vector overloads to `createVector()` for consistency

[GregStanton]

[2.0] Add array, vector overloads to createVector() for consistency

Currently, vector operations often allow vectors to be specified in three ways: separate number arguments, a number array, or a vector instance. For example, add(), sub(), mult(), div(), and rem() all work this way. Ideally, we would always allow users to specify vectors in the same ways, so they don't need to guess which vector features accept which overloads. We already do this with color features like fill() and stroke(), which have a consistent set of overloads for specifying colors.

~~If adding array and vector overloads to createVector() sounds good, then we might also consider deprecating the copy() method, as it would no longer be needed: v.copy() could be replaced by createVector(v).~~

Edit: We don't plan to deprecate copy(). See this comment.

Tasks:

• [ ] Reach consensus on adding overloads
• [ ] Implement and document

[kunal-595]

Hii @GregStanton , i would love to work on this issue as my first contribution to the organization , could you please assign it to me ?

[ayushman1210]

hi @GregStanton could you please assign me this issue ?

[lokesh-singhal]

Hey @GregStanton, I’d like to work on this issue. We can use x instanceof p5.Vector to handle vector inputs and Array.isArray(x) for array inputs inside createVector(). Could you please assign this issue to me so I can implement it?

[davepagurek]

+1 for allowing more overloads in createVector. I think .copy() maybe has enough of a separate use that it doesn't need to be deprecated though. Because vectors can't use regular math operations and rely on methods, users make extensive use of method chaining. A .copy() fits well into the feel of this, and having to wrap something in createVector(...) breaks that flow. Also using createVector(...) to create a copy, while it makes sense that it should work, feels like a slight indirection from an initial intent of "I want to create a copy of this object." Those are all fairly minor points, but between that and the heavy use of .copy in the wild, I'm not sure API simplification alone is strong enough to justify deprecation.

[GregStanton]

I think .copy() maybe has enough of a separate use that it doesn't need to be deprecated though.

Excellent point, thanks Dave! I think that makes sense.

[avinxshKD]

@GregStanton I'd like to work on this. Please assign it to me if it's available. Thanks

[GregStanton]

Hi @kunal-595, @ayushman1210, @lokesh-singhal, and @avinxshKD! Thank you all for offering to help. We first need to reach consensus on the changes that need to be made, since these would affect the user-facing API. However, I suspect adding overloads to createVector() will be uncontroversial, since it's for consistency with many other methods that already have the same overloads. If you think we don't need further consensus @davepagurek, then we could assign the issue to @kunal-595, as they were the first to volunteer.

[vtushar06]

Hi @GregStanton,

It's been 2-3 weeks since @kunal-595 volunteered, and I'd love to take on this issue if it's still available. I've reviewed the implementation approach (using instanceof p5.Vector and Array.isArray() checks) and I'm ready to implement, test, and document the changes.

@kunal-595 - Let me know if you're still working on this! Otherwise, I'm happy to proceed.

Thanks

[kunal-595]

Hi @vtushar06 , i am still working on it .

[GregStanton]

Hi @kunal-595! Thank you so much for your help and patience! I went ahead and assigned this issue to you, but I'm still hoping to get final approval for this change before implementation begins, since it affects the user-facing API. Do you think we can go forward on this @davepagurek?

[davepagurek]

This is good to go ahead, thanks @kunal-595!

[Shubhamkahar196]

Hi @GregStanton 👋,

I’m Shubham Kahar, and I’m interested in contributing to p5.js as a new contributor.
I see this issue (#8157) is already assigned to @kunal-595 — just wanted to say this is a really interesting enhancement idea and aligns with my skills in JavaScript and vector math.

I’d love to help with testing, documentation, or similar upcoming issues related to p5.Vector or p5.js 2.0 features.
Please keep me in mind if there’s another related task or beginner-friendly issue I could take on. 😊

Thank you!

[GregStanton]

Hi @Shubhamkahar196! Thank you so much for your interest. You can follow the broader stabilization effort for p5.Vector in the umbrella issue #8149. All current issues can be found there, and additional planned issues will be posted there as well. All current issues that are unassigned are blocked, since we need final approval on some core policies before work can proceed.

If you'd like to help out, the best thing you can do is to add a comment to the issues below, to indicate whether or not you support the proposals they contain. This will help the maintainer team to assess community consensus.

• #8153
• #8155
• #8159

Once these issues are approved, work will become possible on a range of existing and planned p5.Vector issues. (A fourth blocking issue is #8156, but public discussion of that issue is currently on hold, per the discussion in PR #8203).

We typically assign work on a first come, first served basis. If you'd like to be notified when new p5.Vector issues are posted, you can subscribe to the umbrella issue #8149. I also recommend subscribing to the sub-issues #8152, #8155, #8158, and #8159, as these may get new sub-issues of their own. Thanks again for your interest Shubham!

[Shubhamkahar196]

Hi everyone 👋

I'm Shubham Kahar, a new contributor interested in helping with the p5.Vector stabilization effort for p5.js 2.0.
I have experience in JavaScript, vector math, and frontend development, and I find this area particularly exciting because consistent and predictable vector behavior directly improves both performance and creative coding workflows.

After reviewing the current proposals, I support the plan to:

• Standardize the x, y, z, and w fields for clear API consistency.
• Clarify or document the dimensions field to reduce ambiguity.
• Define a uniform policy for dimension mismatches, which will make function chaining and overloads far more robust.

I've subscribed to this umbrella issue and the related sub-issues (#8153, #8155, #8159, etc.) and will be happy to assist with testing, documentation updates, or implementation once the blocking issues are approved.

Looking forward to learning from everyone here and contributing to the p5.js 2.0 evolution 🚀

[ksen0]

Hi everyone, thanks so much for all the lively discussion of the p5.js 2.x Vector implementation! Now that that 2.1 is released, we wanted to set up a more direct discussion space for p5.js 2.x Vector implementation bugfixes, documentation, and improvements. So, here is a Discord channel: https://discord.gg/gH3VcRKhen

As we discuss/unblock each of the vector issues, I will also follow up on those issues as a comment. So if you prefer to participate only (or primarily) on GitHub, that still also works!

[Nitish-bot]

Hey @kunal-595, this issue has been stale for quite some time now. Let me know if you need any help, I'd like to take the issue up if you are no longer working on it.