Closed lynn-lumen closed 6 days ago
I'm personally of the mind that the primitive_Nd
functions should probably just take the primitive argument by reference; I wouldn't be surprised if they were initially conceived under the assumption that primitives would be Copy
. That unfortunately breaks existing code, but I think it's the semantically correct approach.
I'll get started on implementing this, probably tomorrow.
What problem does this solve or what need does it fill?
Currently
gizmos.primitive_2d()
andgizmos.primitive_3d()
require a parameter of typeP: PrimitiveNd
. Passing&my_primitive
is not allowed. This is fine and barely noticeable for primitives that implementCopy
but those that don't, likePolygon<N>
orBoxedPolyline
, need to be cloned every time they are drawn using gizmos (Theexamples/math/render_primitives
avoids this by having all primitives beconst
).Some solutions
Since the
primitive_Nd
functions do not do anything that could not be done with&my_primitive
as of now, they could just accept this as a parameter instead. This would obviously cause existing code to be rewritten (gizmos.primitive_2d(PRIMITIVE)
->gizmos.primitive_2d(&PRIMITIVE)
) which is rather annoying.We could introduce a new trait akin to
GizmoRefPrimitiveNd<P: PrimitiveNd>
with a functionprimitive_ref_Nd(primitive: &P, ...)
that accepts primitives by ref.GizmoRefPrimitiveNd
could probably even be implemented automatically for primitives implementingGizmoPrimitiveNd
.If we allow
bevy_math
to be changed to fix this, we could implementPrimitiveNd
for&P
where P is some Primitive that does not implementCopy
. This would allow implementingGizmoPrimitiveNd<&P>