Mint integration needs to suck less.

[icefoxen]

10:36 < Icefoz> I can convert nalgebra and cgmath types into mint types and back, but it still doesn't really let me conveniently turn them into each other.
10:40 < Icefoz> I can't do cgmath::Vector3::from(nalgebra_vector3) or such, or even cgmath::Vector3::from(nalgebra_vector.into())
10:41 < Icefoz> It needs a type annotation and neither from() nor into() take a turbofish so I'm not really sure where to put it.
10:43 < kvark> Icefoz: why do you need to go between cgmath and nalgebra directly?
10:43 < Icefoz> I can't even do cgmath::Vector3::<f32>::from(mint::Vector3::<f32>::from(v1)) because nalgebra::Vector3 implements Into<mint::Vector3>, instead of mint::Vector3 implementing Into<nalgebra::Vector3>
10:44 < Icefoz> kvark: Because otherwise it's a pain in the butt.
10:44 < Icefoz> If I'm doing all my math using cgmath but need to turn things into nalgebra types to feed into ggez, I want to be able to do ggez::graphics::draw(..., cgmath_vector.into())
10:45 < kvark> Icefoz: please explain the use case. The way I see it is: mint is in the API (either directly, or generically as Intomint::XXX. User passes in cgmath types, they get converted to mint. You convert mint->nalgebra. Nowhere you'd need to go between cgmath and nalgebra.
10:45 < Icefoz> Not let this_stupid_conversion_work: mint::Vector2<_> = cgmath_vector.into(); ggez::graphics::draw(..., this_stupid_conversion_work);
10:45 < Icefoz> Hmmmm.
10:46 < Icefoz> That would work but is an API break for ggez.
10:46 < Icefoz> And involves an extra copy.
10:46 < Icefoz> But it would work.
10:46 < Icefoz> I misunderstood the intent then.
10:48 < kvark> yeah, I don't think trying to add this as an extra feature is a good way forward. You either decide to switch to be math-agnostic, or keep using nalgebra.
10:48 < Icefoz> Well I can at least add the feature flag so it's possible to do it the lame way.
...
10:54 < Icefoz> With the ergonomics being what they are it'd almost be easier to make bindings for nalgebra, cgmath and euclid to talk to each other directly.
10:54 < Icefoz> It's n^2 complexity but small n
10:54 < kvark> how is this better than using mint?
10:55 < Icefoz> You could use ggez::graphics::draw(..., cgmath_vector.into())
10:56 < Icefoz> I hesitate to turn every function call in ggez that takes a Point into a morass of generic arguments, since that tends to be hard for newbies to grok.
10:56 < kvark> with mint, as I said, you could even use "ggez::graphics::draw(..., cgmath_vector)" if the API is written generically (accepting Intomint::XXX). That's what three-rs is doing
10:56 < kvark> and if you don't need generics, you can get the same "ggez::graphics::draw(..., cgmath_vector.into())" with mint. I feel like you are missing or not telling something here
10:57 < Icefoz> I hadn't thought of that second point.
10:58 < kvark> btw, nical - ping
10:58 < Icefoz> The downside there is that people can't do mint_vector_a + mint_vector_b and that will just confuse people in a different way.
10:58 < nical> kvark: sup ?
10:58 < Icefoz> (Maintaining ggez has made me very averse to doing things that will confuse newcomers. :-P )
10:58 < kvark> Icefoz: they aren't supposed to use mint, unless they really want to
11:01 < kvark> nical: i.e. it computes a dot product of each column with the vector. Instead of going dot(row, vector)
11:01 < Icefoz> kvark: But mint will be in every function signature ever, so it will get used. Good docs will help but don't fully solve the problem.
11:01 < kvark> Icefoz: right, that's a downside
11:02 < Icefoz> It might be worth it. I'll have to think about it.
11:03 < Icefoz> I may or may not be worrying about this too much.

[icefoxen]

This is relevant to both #367 and #106 .

[icefoxen]

Well in progress as of commit 200ce3e and it is awesome.