Cool. I was afraid that it will be harder for the compiler to optimize away the enum, but it seems to be doing fine. (If it does turn out that it's harder for the compiler, I don't see a real problem with the approach I suggested, as a runtime failure can only be caused by a bug in the code generator, not by user code)
On Thu, Jun 12, 2014 at 2:13 AM, Kevin Cantu <[email protected]> wrote: > Matthew Monrocq suggests this improvement, which looks even cleaner to > use, although slightly more complicated to implement generation of: > > > On Wed, Jun 11, 2014 at 11:38 AM, Matthieu Monrocq < > [email protected]> wrote: > >> [snip] >> >> I do like the idea of the trait, however I would rather do away with all >> the `get_aa`: why not directly wrap the parameters ? >> >> enum AaBbEnum { >> Aa(int, f64), >> Bb(f64), >> } >> trait AaBb { >> fn get(&self) -> AaBbEnum; >> >> } >> >> impl AaBb for (int, f64) { >> fn get(&self) -> AaBbEnum { match *self { (i, f) => Aa(i, f), } } >> } >> >> impl AaBb for (f64) { >> fn get(&self) -> AaBbEnum { Bb(*self) } >> >> } >> >> fn overloaded<T: AaBb>(x: T) { >> match x.get() { >> Aa(i, f) => println!("got Aa: {}", (i, f)), >> Bb(f) => println!("got Bb: {}", f), >> >> } >> } >> >> #[main] >> fn main() { >> overloaded((5i, 7.3243)); // prints: got Aa: (5, 7.3243) >> overloaded((3.5)); // prints: got Bb: 3.5 >> } >> >> Now, there is no runtime failure => you cannot accidentally match on `Bb` >> and requests `get_aa`! >> > > > > Kevin > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
