> 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.
Yes, that's how trait resolution currently works. There is an RFC on
that which turns traits into something resembling type classes in
Haskell, with proper resolution of overlapping instances:
https://github.com/rust-lang/rfcs/pull/48, however, I'm not sure if it
will help in this case.
Currently if you want to implement `ToStr` manually, you should
implement `std::fmt::Show` instead:
use std::fmt;
impl fmt::Show for Test {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
write!(f, "{}", self.a)
}
}
Now you can use `to_str()`:
let t = Test { a: 10 }
println!("{}", t.to_str()); // 10
2014-05-29 6:17 GMT+04:00 Oleg Eterevsky <[email protected]>:
> 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
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
