Hi Patrick,
> If the signature is wrong and we mistakenly freeze it, we can just introduce
> a new function with a different name.
But this is a severe design issue, to introduce new function names. This makes
generic programming impossible. Now the user has to distinguish between
the types, but this is the task of the compiler.
> Overloading only helps some simple cases, and adds more complexity than it's
> worth (IMO).
Overloading is the only way to specialize functions, and this is the only way
to allow generic programming. Without specializing we are back to the bad
old days, where the user has to call the appropriate function for a specific
object, but in a modern programming language the compiler is doing these
things.
> The problem with C++ isn't that it doesn't have enough features. Rust is
> deliberately omitting some features from C++ that don't pull their weight.
> Overloading is one of them.
I think that some weights are unavoidable. And I cannot see serious drawbacks
with function overloading, but I see serious drawbacks without:
As I saw Rust the first time, I was impressed, and I decided to overwork the
big integer module (I've already written a big integer library in C), because
the current impementation is much too slow, it suffers from:
1. too many memory allocations
2. some algorithms are a bit naive.
And at first I tried to specialize std::num::pow(), but I gave up immediately,
because I cannot specialize. And without specializing this function I cannot
realize a proper implementation and design, and I'm never doing half-baken
things. So I gave up at all.
The current design in Rust does not allow:
1. Generic programming, in current design of Rust the user has to know,
which function to call for a specific object, and has to use switch (or match)
statements to call it (and if he forget the right functions and uses
std::num::pow(), his program will suffer). This is a programming style 30 years
ago, as I started to write programs.
2. Uniform function signatures, currently the user has to decide about using a
reference or not, but the compiler should decide. If the compiler is deciding,
whether an argument is given by value or by reference, then the problem with
the signature will vanish. And the compiler is better to decide than the user.
One more advantage: the user must not know whether to use a reference
or not when calling a function/method. One exception: a mutable argument, in
this case a reference will be used explicitely by the user, when specifiying
the signature, and when calling the function.
One more drawbacks without overloading: The user defines two print methods:
pub fn print(line : string) -> bool;
pub fn print(line : string, max_line_length : uint) -> bool;
Not possible, he has to use different names. An alternative definition would be:
pub fn print(line : string) -> bool;
pub fn print_with_maxlen(line : string, len : uint) -> bool;
30 years ago this was the normal way, but nowadays, it's a No-Go.
The current status of Rust is: it does not allow proper software design. And
that's bad, because a successor for C++ is needed. Of course, a successor
of C++ does not mean: a better C++. It means, a completely new language
conecept, like Rust. And it does not mean: avoid the good things of C++,
like specialization of functions.
Cheers,
Gregor_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
