Noam, that's awesome. It even works for tuples like so (I didn't think it
would):
```
enum AaBbEnum {
Aa,
Bb,
}
trait AaBb {
fn get_type(&self) -> AaBbEnum;
fn get_aa(self) -> (int, f64) { fail!(); }
fn get_bb(self) -> (f64) { fail!(); }
}
impl AaBb for (int, f64) {
fn get_type(&self) -> AaBbEnum { Aa }
fn get_aa(self) -> (int, f64) { self }
}
impl AaBb for (f64) {
fn get_type(&self) -> AaBbEnum { Bb }
fn get_bb(self) -> (f64) { self }
}
#[cfg(not(test))]
fn overloaded<T: AaBb>(x: T) {
match x.get_type() {
Aa => println!("got Aa: {}", x.get_aa()),
Bb => println!("got Bb: {}", x.get_bb()),
}
}
fn overloaded_format<T: AaBb>(x: T) -> String {
match x.get_type() {
Aa => format!("got Aa: {}", x.get_aa()),
Bb => format!("got Bb: {}", x.get_bb()),
}
}
#[cfg(not(test))]
#[main]
fn main() {
overloaded((5i, 7.3243)); // prints: got Aa: (5, 7.3243)
overloaded((3.5)); // prints: got Bb: 3.5
}
#[test]
fn overloaded_with_same_return_works() {
// now with a shared return
let x: String = overloaded_format((5i, 7.3243));
let y: String = overloaded_format((3.5));
assert_eq!(x, "got Aa: (5, 7.3243)".to_string());
assert_eq!(y, "got Bb: 3.5".to_string());
}
```
I imagine if the functions being overloaded have different return types,
this gets uglier to use, but this is pretty good!
Kevin
On Wed, Jun 11, 2014 at 4:35 AM, Noam Yorav-Raphael <[email protected]>
wrote:
> You can achieve overloading which is equivalent to C++ by defining a trait
> for all the types a specific argument can get:
>
> ```
> enum IntOrFloatEnum {
> Int,
> F64,
> }
>
> trait IntOrFloat {
> fn get_type(&self) -> IntOrFloatEnum;
> fn get_int(self) -> int { fail!(); }
> fn get_f64(self) -> f64 { fail!(); }
> }
>
> impl IntOrFloat for int {
> fn get_type(&self) -> IntOrFloatEnum { Int }
> fn get_int(self) -> int { self }
> }
>
> impl IntOrFloat for f64 {
> fn get_type(&self) -> IntOrFloatEnum { F64 }
> fn get_f64(self) -> f64 { self }
> }
>
> fn overloaded<T: IntOrFloat>(x: T) {
> match x.get_type() {
> Int => println!("got int: {}", x.get_int()),
> F64 => println!("got f64: {}", x.get_f64()),
> }
> }
>
> fn main() {
> overloaded(5i); // prints: got int: 5
> overloaded(3.5); // prints: got f64: 3.5
> }
> ```
>
> This is equivalent to having to functions, overloaded(int) and
> overloaded(f64). From what I see, the compiler even optimizes away the
> logic, so the generated code is actually equivalent to this:
>
> ```
> fn overloaded_int(x: int) { println!("got int: {}", x); }
> fn overloaded_f64(x: f64) { println!("got f64: {}", x); }
> fn main() {
> overloaded_int(5i);
> overloaded_f64(3.5);
> }
> ```
>
> (I actually think that if Rust gains one day some support for overloading,
> it should be syntactic sugar for the above, which will allow you to define
> a function whose argument can be of multiple types. I don't like the C++
> style of defining several different functions with the same name and
> letting the compiler choose which function should actually be called).
>
> Using this method you can solve both the problem of overloading and
> default arguments. For every possible number of arguments that C++ would
> allow, define a function funcN<T0, T1, TN-1>(arg0: T0, arg1: T1, ...,
> argN-1: TN-1). The function would check the actual types of the arguments
> and call the right C++ function, filling default arguments on the way. So
> the only difference between C++ and Rust code would be that you'd have to
> add the number of arguments to the method name.
>
> It would probably not be easy to generate the required code, but I think
> it would solve the problem perfectly.
>
> Cheers,
> Noam
>
>
> On Thu, May 22, 2014 at 11:27 PM, Alexander Tsvyashchenko <[email protected]>
> wrote:
>
>> Hi All,
>>
>> Recently I was playing with bindings generator from C++ to Rust. I
>> managed to make things work for Qt5 wrapping, but stumbled into multiple
>> issues along the way.
>>
>> I tried to summarize my "pain points" in the following blog post:
>> http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5
>>
>> I hope that others might benefit from my experience and that some of
>> these "pain points" can be fixed in Rust.
>>
>> I'll try to do my best in answering questions / acting on feedback, if
>> any, but I have very limited amount of free time right now so sorry in
>> advance if answers take some time.
>>
>> Thanks!
>>
>> --
>> Good luck! Alexander
>>
>>
>> _______________________________________________
>> Rust-dev mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
