Conventionally, unsafe in Rust is used strictly for memory safety issues.

Yes, but it's also used in cases where there is a promise that a certain type must have some limitation (being normalized in this case).

All the NonZero number types in the standard library of examples of this.

Having a direction vector that is not normalized may not cause UB in the traditional sense, but it could cause unforeseen bugs.

All the NonZero number types in the standard library of examples of this.

NonZero are used for niche optimization; if you create a zeored 'NonZero', then some code becomes unsound.
The question is: is the invariant of Direction (i.e., a vector is normalized) used as a guarantee in unsafe code?

The question is: is the invariant of Direction (i.e., a vector is normalized) used as a guarantee in unsafe code?

No, but it almost certainly cause bugs in code that expect Direction to be normalized.

Marking it as unsafe makes the user think twice on if their vector is really normalized.

From the Book:

the intent is that as the programmer, you’ll ensure the code inside an unsafe block will access memory in a valid way.

unsafe in Rust is a matter of accessing valid memory. The worst that could happen with a non-normalized Direction is panic; which is a logic bug like dividing by 0.

The worst that could happen with a non-normalized Direction is panic

Panics are arent much of a problem here (they can easily be tracked down), what is a problem is a silent bug (A bug that doesn't provide any debug information when it occurs). For example, if you have a player movement function that takes in a Direction2d and that Direction2d isnt normalized, that cause the player to move slower/faster than expected, and it'll be very hard to track down. (The user will expect Direction2d to be normalized)

The unsafe keyword isn't just for memory issues and UB, it's for places that have a "contract" that the compiler can't check.

The unsafe keyword has two uses:

• to declare the existence of contracts the compiler can't check (unsafe fn and unsafe trait),
• and to declare that a programmer has checked that these contracts have been upheld (unsafe {} and unsafe impl, but also unsafe fn -- see below).

- The unsafe keyword's documentation when hovered over (rust-analyzer)

The "contract" here is that the inner vector is normalized.

As I said earlier, making this unsafe makes the user think twice about if their direction is really normalized. And it makes shooting yourself in the foot harder.

This has been a longstanding discussion in the rust community. "What should I mark as unsafe?" For the standard library, the answer is "only methods with invariants, which, if not upheld, invoke undefined behaviors".

There is even a chapter on the rust reference about "behaviors not considered unsafe": https://doc.rust-lang.org/stable/reference/behavior-not-considered-unsafe.html. "Logic Errors" is in there.

This doesn't answer the question of whether we should mark the method as unsafe. The thing is, we already expose API that assumes the values passed-in represent a normal vector: The Quat constructors. I think we should be consistant with our API, and it makes sense to not mark the constructor as unsafe, the same way glam doesn't. We could add an optional runtime check though!

Well, I guess I'll make it safe.

The thing is, we already expose API that assumes the values passed-in represent a normal vector: The Quat constructors.

Quaternions do not need to be normalized. Only quaternions that are used for rotation do. I've used quaternions to represent angular velocity before, and those were intentionally not normalized.

In nalgebra, there's UnitQuaternion specifically for rotations, but there's nothing similar in bevy/glam.