Thanks for the detailed reply. I agree that overloaded functions can be used to shoot yourself in the foot. Fortunately, I haven't yet seen any code that I would care to read, designed so badly that overloaded functions would do essentially different things depending on the number or type of arguments.
The problem with too many versions of a function in C++ is quite real, but they are there for a reason: they are usually required to deal with different combinations of references and const parameters. As to the last objection, it is very much dependent on the API in question. Those overloads may sometimes be beneficial. In any case, I do not think that a feature of the language that has legitimate uses should be banned just to prevent bad programmers from abusing it. On Wed, May 28, 2014 at 8:10 PM, comex <[email protected]> wrote: > On Wed, May 28, 2014 at 10:17 PM, Oleg Eterevsky <[email protected]> wrote: >> Suppose, I want to add a new argument to a function in a >> backwards-compatible way. In Python I provide a default and everything >> works fine. In C++ or Java I write something like > > This came up a few days ago in the discussion about Qt bindings. > > I associate function overloading with pitfalls like: > - Methods which do different things depending on the number or types > of arguments. Very very bad, since it's difficult to tell which > overload is being used by skimming, and differences in functionality > deserve names - but from my memory, rather common in practice. > - Not being able to tell which overload is being used, even looking > relatively closely, because of conversion wonkiness. Admittedly > wouldn't really be a problem in Rust the way it is in C++, but if the > alternatives depend on traits, you might have to figure out which > trait the object you passed is actually using. > - Excessive number of overloads for convenience, which are all > specific to that method, requiring a bunch of boilerplate to implement > and not generalizing for the API user to others. For example, from > that discussion, > http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect - where, e.g., > just asking the user to write QRect(x, y, w, h) instead of passing x, > y, w, h as arguments would save several overloads. > > Though this doesn't apply to your example, many convenience types of > overloads can be emulated using traits. > > On the other hand, I generally like keyword and default arguments. > However, from my experience in Python it's often necessary when > function A wraps function B to have the same default value in both > declarations, which is problematic if the default needs to change. > (Not *necessary* exactly, since passing around *args, **kwargs works > too, but I'm not sure what that would look like in Rust, and I avoid > it in Python because it makes it less clear from the declaration what > arguments the method accepts.) Thus I think it might be better to > make argument presence or absence somehow syntactic sugar for passing > an Option rather than the usual behavior of specifying a default. But > I don't know what the contributors think about it. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
