Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah I found it somewhat surprising too. Coming from kotlin I had expected this to be similar to extension methods but apparently not. I never fully understood the motivation behind this restriction.


Suppose I use Jim's birds crate, Sarah's noises crate and Hannah's shape crate.

If Hannah is allowed to write

impl birds::Goose { fn fudge(&mut self) { self.counter += 1; } }

and Sarah is allowed to write

impl birds::Goose { fn fudge(&mut self) { self.counter -= 1; } }

... Now what happens when I call fudge on a Goose? Does it increment the counter? Or decrement the counter? If instead the program is rejected because of the ambiguity, whose fault is the ambiguity? Sarah's fault? Hannah's fault? Jim's fault?


I'd get what I import (explicitly). If I import conflicting extensions then its my fault for doing so and (only) my program fails to compile.


You cannot import specific inherent methods. What you can do though is use the extension trait concept and import those traits.

If you import both traits you get an ambiguous function error and are asked to resolve which trait you want `<Goose as noises::Trait>::fudge(...)`.


Ah, I was not aware of extension traits. Thanks for pointing out.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: