I have the feeling this should have a simple solution but I'm struggling a lot with this problem. Since I'm not using generic types I'm lost in regards to what to use as an associated type, for instance.
iterator can only have a single return type so you cant have an iterator that either returns f32 or f64 but you can have a single type which is f32 or f64
thank you both for your fresh ideas, I'm gonna have to ponder on this some more.
So if my real enum has about 20 types then I'd have to return an enum with 20 variants and figure out ways to reduce that complexity, maybe with a bunch of impl Into<...>.
@quinedot the second proposal is not an option for me, since not all the values are able to be coerced.
Do you have a simple example of how your last proposal of iterating on the underlying vec would be? I'm not sure I'm visualizing it right. Do you think that'd be feasible if my real enum has more levels of nesting?
This would be the parent level of the enum to iterate on, but there are more levels:
(This won't be practical for your 20 variants, but we were racing in our replies...)
Another alternative to iteration is to turn it inside out and have consumers of FloatVec supply the body of the loops as closures (one for f32s and another for f64s).
I like very much your example using closures, it's very interesting! but you're right that's not gonna fly in my case, because of the number of variants and I also have vecs of strings, and other types...
So in my mind the 20 variant enum return type solution is the most promising. The other option I'm considering would be to refactor everything with generics but that would probably mean a different set of problems... And I was very happy with the system until I had to tackle iterators...
I just meant something like this where you branch on the underlying type before looping, so you have one loop per variant (instead of branching each iteration inside one loop).
I've done similar things and it does lead to a lot of repetition and boiler plate, which you can reduce somewhat with generics and/or macros.
Now I just made the function a method, and a single constructor that can accept a vec directly, and I really like where this is going (updated example),
I also like this can work alongside the other solution of returning an enum. Which also has a lot of potential...