impl Into<[f32; 2]> also makes sense.

It does, but for more complex types, mint support is nice. I'm not sure if that'll come up but it's a good crate to support I think

Hello all -- this has now covered the API. Please let me know if you have any thoughts or opinions -- some of these bounds are a bit rough (especially the InputFloatX and ColorPickerX and ColorEditX widgets). Until mint upgrades, we can't simplify. I added an issue to them here kvark/mint#67

since the above would be a patch we'd be safe to go to 0.5.7.

I'm failing some of the tests, but will fix over the weekend. that mostly is because this includes a breaking change where the ColorPicker and ColorEdit structs where de-genericed to just ColorPicker3 and ColorPicker4, since their generic Into nature was just...a mess.

This looks like a good improvement!

With the caveat that I have almost no idea what I'm talking about: could this potentially have a noticeable impact on binary size due to monomorphization? I have even less idea of how it works in regards to #[inline] methods, but basically could something like

#[inline]
pub fn size(mut self, size: impl Into<crate::math::MintVec2>) -> Self {
    self.size = size.into().into();
    self
}

...mean that user-code like

fn some_giant_function(ui: &imgui::Ui) {
    ui.whatever().size([0.0, 1.0]);
    ui.whatever().size(some_vec);
    ui.whatever().size(some_other_vec);
    // and lots more calls
}

..would end up with lots of copies of some_giant_function with the various permutations of .into().into()?

I had a quick search around and only related-ish thing I could find was rust-lang/rust#77767 so I suspect it probably isn't a big problem

not like that -- it would work the other way around though.

So there will only be one some_giant_function (you can tell since it has no generic type parameters), but there WILL be have at least three (assuming some_other_vec is another T: Into<MintVec2>) implementations of .size on it.

Morever, if you noticed, I actually put the trait bound on the impl block itself, so you can't .size with different concrete types. Actually, supporting that wouldn't be that difficult, but that sounds NEEDLESS.
So that's the say, this wouldn't work...

ui.window("hello")
   .size([10.0, 20.0])
   .size(glam::Vec2::splat(100.0)) // error, expecting [f32; 2]

However, if a user is using two different math libraries, or freely using arrays + a math library, their binary size will definitely increase.

That doesn't overly concern me atm, but what are you thinking? I will say that the compile time increase that this would create somewhat worries me, but since we had #[inline] over most of these functions anyway (and generic code is always a candidate for inlining, even across crate boundaries), it seems like the impact would be too serious.

At least on my end, I've been fairly extensively using the draw API for a node graph editor at work, and being able to use glam instead of arrays will wildly simplify that work

I will say, for a normal math library like glam or vek, we end up at a pretty nice performance situation. We do pay to switch to an from the [f32; 2]` types, though we use some fast instructions on this x86_64 backends: https://godbolt.org/z/sdx4exvMf

Ahh yeh that makes much more sense (for some reason I half-thought inlining a generic function would make the calling function generic, but on actually thinking about it, that.. wouldn't make much sense!)

As long as there isn't much overhead if people exclusively use [f32; 2] then it's hard to see much issue with any potential overhead if someone decides to use 23 different vector types 😁

At least on my end, I've been fairly extensively using the draw API for a node graph editor at work, and being able to use glam instead of arrays will wildly simplify that work

I've been using euclid for similar purposes and although adding .to_array() each time isn't too bad, removing the need for that would be another minor im_str!-like papercut gone 🥳