Thanks for your answers. Can't say I understand or agree with all the decisions.
> 1. Not everyone prefers overloaded functions, or default arguments.
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
fn test(old_arg: int, new_arg: int) {
...
}
fn test(old_arg: int) {
test(old_arg, 0)
}
and everything is still good. What should I do in Rust?
> 2. Design decision. Basically, we take Erlang's philosophy: recovering
from errors is tricky and error-prone.
So basically this mean that you could emulate exceptions by running a
co-routing and catching its state? It makes sense, though it sounds
like it overcomplicates things a bit from programmer's perspective.
Also I'm a bit worried about the number of unwrap's.
>> 4. It looks like vectors can be concatenated with + operations, but
strings can't. Is it deliberate?
> 4. I believe so, yes. We try not to be overload-heavy.
In my experience + is much more often used for strings than for
vectors. Is it not?
> 6. I believe there is a default implementation, yes.
It happens even for this:
struct Test {
a: int
}
impl ToStr for Test {
fn to_str(&self) -> String {
self.a.to_str()
}
}
As you can see, Test is not implementing Show, so I assumed that I
could implement ToStr instead. I suspect that there is somewhere an
implementation
impl<T: ToStr> Show for T
and after I implemented ToStr, Test automatically became an
implementation of Show, which in turn led to conflict. I might be
wrong though. I'd like to note that if there was a sane implementation
of overloaded functions, this could be resolved.
On Wed, May 28, 2014 at 5:47 PM, Steve Klabnik <[email protected]> wrote:
> A few quick intro answers. Just the high level, not comprehensive.
>
> 1. Not everyone prefers overloaded functions, or default arguments. I
> know pcwalton has strong feelings about the first, so I'll leave him
> to that :)
>
> 2. Design decision. Basically, we take Erlang's philosophy: recovering
> from errors is tricky and error-prone. Better to let a task fail and
> start a new one rather than to try to re-start one in the middle of
> whatever it's doing.
>
> 3. No opinions, but know that all of this has been changing a _lot_
> recently, this may even be planned.
>
> 4. I believe so, yes. We try not to be overload-heavy.
>
> 5. This is being worked on. Vec is a new construct anyway.
>
> 6. I believe there is a default implementation, yes.
>
> 7. I'm not even getting into this one. There's been a toooooon of
> discussion about this lately.
> https://github.com/rust-lang/rfcs/search?q=mutability&ref=cmdform&type=Issues
>
> Hope that starts to kick off some good discussion. :)
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
