Hi Patrick,
Thanks for your answer! See comments below. On 2014-05-23 06:12, Patrick Walton wrote: > You can use "extern "Rust" fn" (or ||:'static) to achieve something like > C++03 member function pointers without the lifetimes. Do I understand correctly that by "extern "Rust" fn" you mean taking the pointer to the global function? If yes, then I'm definitely aware of the possibility to do that, but it is not helpful in the context of signals / slots. Please see my Reddit comment for more detailed explanation: http://www.reddit.com/r/rust/comments/269t6i/cxx2rust_the_pains_of_wrapping_c_in_rust_on_the/chpfi1o RE: (||:'static) - as you can see in my initial post, this is what I ended up using - only without the explicit 'static annotation, but with the same restriction of not having any captured state. I agree that from what I've seen so far, ||:'static seems to be the closest thing to member function pointers - but I'd argue it's still not the full replacement as it's more verbose - that is, requires explicitly passing the state + declaring & forwarding all function arguments, e.g. instead of "slot(&obj, &Class::method)" it's "slot(&obj, |obj, arg1, arg2, arg3, arg4, arg5, arg6, arg7| { obj.method(arg1, arg2, arg3, arg4, arg5, arg6, arg7) })". And yes, there are signals with up to 7 arguments in Qt5 ;-) > I am opposed to function overloading and default parameters. I do not see it > as a burden to define meaningful unique function names. On the contrary, this > helps greppability in large codebases. Yes, I do realize there are quite strong opinions regarding function overloading and default parameters within Rust development community. I hold strong opinions on this subject too, and these happen to be the opposite ones to what you have - which is the perfect background to start flame war, which I have zero interest in ;-) Therefore, I suggest we move from the question "are function overloading and default parameters good or bad?" to the question "Lots of existing C++ libraries use function overloading and default parameters. How Rust should deal with wrapping these?" I believe the answer to this question is important because with all the optimism around Rust adoption, I doubt all existing C++ libraries that were developed over the last decades (Qt including) will be magically re-implemented in Rust within the next year or two. So far I can imagine several possible answers: * "We don't care, your legacy C++ libraries are bad and you should feel bad!" - I think this stance would be bad for Rust and would hinder its adoption, but if that's the ultimate answer - I'd personally prefer it said loud and clear, so that at least nobody has any illusions. * "Define & maintain the mapping between C++ and Rust function names" (I assume this is what you're alluding to with "define meaningful unique function names" above?) While this might be possible for smaller libraries, this is out of the question for large libraries like Qt5 - at least I won't create and maintain this mapping for sure, and I doubt others will: just looking at the stats from 3 Qt5 libraries (QtCore, QtGui and QtWidgets) out of ~30 Qt libraries in total, from the 50745 wrapped methods 9601 were overloads and required renaming. Besides that, this has a disadvantage of throwing away majority of the experience people have with particular library and forcing them to le-learn its API. On top of that, not for every overload it's easy to come up with short, meaningful, memorable and distinctive names - you can try that exercise for http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect ;-) * "Come up with some way to allow overloading / default parameters" - possibly with reduced feature set, i.e. if type inference is difficult in the presence of overloads, as suggested in some overloads discussions (although not unsolvable, as proven by other languages that allow both type inference & overloading?), possibly exclude overloads from the type inference by annotating overloaded methods with special attributes? * Possibly some other options I'm missing? -- Good luck! Alexander
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
