Alexander, your option 2 could be done automatically. By appending postfixes to the overloaded name depending on the parameter types. Increasing the number of letters used till the ambiguity is fully resolved.
What do you think? fillRect_RF_B ( const QRectF & rectangle, const QBrush & brush ) fillRect_I_I_I_I_BS ( int x, int y, int width, int height, Qt::BrushStyle style ) fillRect_Q_BS ( const QRect & rectangle, Qt::BrushStyle style ) fillRect_RF_BS ( const QRectF & rectangle, Qt::BrushStyle style ) fillRect_R_B ( const QRect & rectangle, const QBrush & brush ) fillRect_R_C ( const QRect & rectangle, const QColor & color ) fillRect_RF_C ( const QRectF & rectangle, const QColor & color ) fillRect_I_I_I_I_B ( int x, int y, int width, int height, const QBrush & brush ) fillRect_I_I_I_I_C ( int x, int y, int width, int height, const QColor & color ) fillRect_I_I_I_I_GC ( int x, int y, int width, int height, Qt::GlobalColor color ) fillRect_R_GC ( const QRect & rectangle, Qt::GlobalColor color ) fillRect_RF_GC ( const QRectF & rectangle, Qt::GlobalColor color ) Alexander Tsvyashchenko wrote: > So far I can imagine several possible answers: > > 1. "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. > > 2. "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;-) > > 3. "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? > > 4. Possibly some other options I'm missing? > > -- > 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
