lerp over scalar types?

[TarekAS]

trafficstars

Hello!

I'm using glam via bevy. Ran into a situation where I need to lerp over a single f32 value i.e. non-vector. I couldn't find a function for it in glam, so I would either need use Vec2::lerp and de-structure the single value out of it, or write my own boilerplate code.

Is this even in the scope of this project? Or should this be implemented as utils in bevy?

[bitshifter]

It's probably not unreasonable given there's no lerp on f32, etc. There was some discussion about adding lerp to the core libraries but there was a lot of nuance to it and the idea got dropped (see https://github.com/rust-lang/rust/issues/86269).

Probably this would need to be added as a trait that users could opt in to.

[TarekAS]

So I guess we would need something like this somewhere:

impl f32 {
    fn lerp(lhs: Self, rhs: Self, s: Self) -> Self {
        lhs + ((rhs - lhs) * s)
    }
}

But this causes an error cannot define inherent `impl` for primitive types consider using an extension trait insteadrustcE0390

So, without impl would be:

fn lerp(lhs: f32, rhs: f32, s: f32) -> f32 {
    lhs + ((rhs - lhs) * s)
}

[bitshifter]

It would need to be a trait that has an impl for f32 and f64.

[paul-hansen]

See https://docs.rs/bevy_tweening/0.5.0/bevy_tweening/trait.Lerp.html for a good example of a lerp trait.

Would we want to replace the current lerp methods on VecN, Quat etc. with trait implementations? Might be a breaking change (not sure tbh), but could be beneficial for things like generic animation classes (like how the bevy_tweening library is using it).

[bitshifter]

I wouldn't replace any methods with trait implementations. I avoid using traits for core functionality in glam because I think it makes methods less discoverable.