These are chat archives for rust-lang/rust

23rd
Apr 2018
Sam A. Horvath-Hunt
@SamHH
Apr 23 2018 11:22
What's the right way to specify a struct with method x, wherein x will be differently implemented for each instantiation? I think impl won't work because they need different implementations, and trait doesn't make sense because I want this method to be required in all instantiations. In TypeScript I'd simply define an interface like this:
interface MyInterface {
    other_property: string;
    do_sth();
}

const obj: MyInterface = {
    other_property: 'example',
    do_sth() {
        // whatever
    }
}
Denis Lisov
@tanriol
Apr 23 2018 11:31
@SamHH Why not just a trait MyTrait?
Sam A. Horvath-Hunt
@SamHH
Apr 23 2018 11:32
@tanriol I want to specify that this trait is required of all instantiations. Is that possible?
Denis Lisov
@tanriol
Apr 23 2018 11:32
Instantiations of what?
Sam A. Horvath-Hunt
@SamHH
Apr 23 2018 11:32
The struct which contains relevant properties. (New to Rust, coming from JS/TS, I may be thinking about this all wrong haha)
Denis Lisov
@tanriol
Apr 23 2018 11:33
Rust does not have struct inheritance :-)
Sam A. Horvath-Hunt
@SamHH
Apr 23 2018 11:34
I'm sure I'm using the wrong terminology then :laughing:
I just mean when you create one, i.e. you've defined struct Example {} and you do let eg = Example {}

Maybe it would help if I specified my use case. I'm creating a library that will look in your pwd for any "tasks", and allow you to quickly call one from a list it builds up. For example, if you enter a directory, call the library, and there's a package.json with scripts present (npm), it compiles a list of scripts for you and allows you to quickly run one.

In doing this, my idea was to have the Rust equivalent of an interface called TaskList or similar that to start with has only one property, the file name, and one method, which implements all the logic of parsing the file and returning a list of tasks. This way, given that I'd like this library to cover a lot of different environments going forwards (npm, makefile, Cargo, countless others), it would be relatively maintainable; each supported environment would behave identically even if under the hood the parsing is obviously very different.

What's the most idiomatic Rust approach to this?

Jeremy Lempereur
@o0Ignition0o
Apr 23 2018 11:37
Hey there :) @SamHH I'm not really sure, but it seems like you're trying to use polymorphism. Could this https://doc.rust-lang.org/book/second-edition/ch17-02-trait-objects.html#defining-a-trait-for-common-behavior be relevant ?
I feel like you're trying to put "properties" in your interface though, whereas interface (imho) would only define a set of methods
i think that's what traits do
I feel like your use case is somewhat between interface composition and class inheritance though ^^
Dylan DPC
@Dylan-DPC
Apr 23 2018 11:38
hey there :smile: can you answer a few questions:
1) do you want to this for one struct or different structs that have some common functionality?
2) is the function the same for all the structs or each one has its own implementation of the function?
@samHH
Sam A. Horvath-Hunt
@SamHH
Apr 23 2018 11:40
1) Depends on implementation I suppose, but each "environment" would, one way or another, have identical/predictable properties and methods, e.g. file_name and get_tasks().
2) Different. The logic to get the tasks would necessarily be different for each. That said, I'd like the call signature to be the same per #1.
Denis Lisov
@tanriol
Apr 23 2018 11:41
I'd sketch out something like the following
trait Task { /* ... */ }
trait TaskSource {
    type Task: Task;
    fn new(path: Path) -> Self;
    fn get_tasks(&self) -> Result<Vec<Self::Task>, _>;
    /* ... */
}
Dylan DPC
@Dylan-DPC
Apr 23 2018 11:41
trait is going to solve that for sure
Sam A. Horvath-Hunt
@SamHH
Apr 23 2018 11:42
Thanks guys, I'll give that a try! :-)
Denis Lisov
@tanriol
Apr 23 2018 11:42
Then I'd store a list of all tasks found in a Vec<Box</*dyn*/ Task>>
Manuel Holtgrewe
@holtgrewe
Apr 23 2018 16:09
I have an error created by the quick_error crate. How can I make a function return Result<_, ThatError> work with the ? syntax in a function that returns Result<_, String>?
Ingvar Stepanyan
@RReverser
Apr 23 2018 16:15
You'll need to implement From<ThatError> for String
(or that person can just convert it themselves with .map_err(...)?)
Michal 'vorner' Vaner
@vorner
Apr 23 2018 20:17
Hello. Is there some (reasonable short) way to write this, but in a way that compiles? (a is a slice, I want to split it into quarters into variables):
let [a00, a01, a10, a11] = a.chunks(block).collect();
Kevin Choubacha
@kbacha
Apr 23 2018 20:29
I was just looking for something like that. I know that slice matching is coming and part of it is being stabilized. The all aspect is seemed like it might be one of the last parts to be stabilized: rust-lang/rust#23121
Michal 'vorner' Vaner
@vorner
Apr 23 2018 20:31
I'm afraid I'm also missing the collect part :-|.