Returning Nan from normalize is bad

[cybersoulK]

we should probably return a Result from it. or the worst case, panic.
because normalize is used a lot in (distance.1 - distance.2).normalize()
and there is a small chance that they are exactly the same,
and like me for hours, trying to hunt for a bug and not able to replicate it.

[bitshifter]

I'd recommend using https://docs.rs/glam/latest/glam/f32/struct.Vec3.html#method.try_normalize or enabling the debug-glam-assert or glam-assert features to check for invalid usage.

The design philosophy of glam is it doesn't typically check data is valid by default as there is an overhead to doing so. It is up to the user to check, glam does try to provide opt-in methods that do check validity however.

[cybersoulK]

this is just not good for beginners like me. i am good now after harsh learning, i will use normalize_zero for most of my cases. but for begginers they will likely use .normalize and that will create undefined behaviour in their apps

[cybersoulK]

if one is sure that the length is always big enough, then you can normalize().unwrap() everytime
and it would be much more clear this way

[cybersoulK]

in games, when i want a direction from one object to another, i am not thinking of checking at all the both positions are overlapping, because we are thinking of two separate objects. but it can happen, and it's super hard to track down when it does. For example, player spawning in the same location as an enemy, ad the enemy wants to chase the player with normalized direction.

[bitshifter]

this is just not good for beginners like me. i am good now after harsh learning, i will use normalize_zero for most of my cases. but for begginers they will likely use .normalize and that will create undefined behaviour in their apps

To be fair, glam wasn't designed with beginners in mind as such, it's been great that it's been adopted much wider than I anticipated. glam is designed to be easy to use but also to be fast and to not make users pay for things they don't need. For example, typically if I am normalizing a vector which could be zero length I will code for that possibility, often though I know the vector will not be zero and checking the length is wasted overhead. NaNs do not constitute undefined behaviour, they pose no memory safety risks.

Perhaps turning back the clock I could have made fn normalize(self) -> Option<Self> and fn normalize_unchecked(self) -> Self. At this point however changing the return type of normalize would break everyone's code and I do not think that all glam users would appreciate the change.

As I mentioned there are other options if you need to check the result, these are mentioned in the documentation for the normalize methods. If there is more that could be done to clarify this in the docs I'm happy to take suggestions.

I'm going to move this to discussions, as I don't intended to change the signature of normalize however I think it's a useful discussion point to keep around.