Source?
-
-
I'll push a wip commit in a few minutes and link you
1 reply 0 retweets 0 likes -
Nowhere near complete: https://github.com/mgattozzi/github-rs/commit/7f38c6ef3cced70435eb0fc7d440525cf34cd3a2 … Relevant Docs: https://developer.github.com/v4/
2 replies 0 retweets 0 likes -
Replying to @mgattozzi
Learned the hard way that you almost never want trait bounds on a struct itself. Only on the methods where it's needed
2 replies 0 retweets 0 likes -
Replying to @sgrif
So just A: Actor and no where clause? The field itself requires something that implements Actor according to the spec.
3 replies 0 retweets 0 likes -
Replying to @mgattozzi
No where clause at all. There's nothing about `Option<A>` that requires it to be an actor.
1 reply 0 retweets 0 likes -
Replying to @sgrif
Then it's generic for any type when the restriction is Actor. Oh I get it. Any place I use it I should just have the fn put the restriciton!
1 reply 0 retweets 0 likes -
Replying to @mgattozzi
Exactly. Or the impl block where the function is added
2 replies 0 retweets 0 likes -
Replying to @sgrif @mgattozzi
HashMap is a good example: https://doc.rust-lang.org/nightly/std/collections/struct.HashMap.html … The key always needs to be `PartialEq + Hash`, but that's not on the struct
1 reply 0 retweets 1 like -
Replying to @sgrif
Just make the functions have the restriction consistently. It'll be a bit more book keeping but not so restricitive I can't do anything! :D
1 reply 0 retweets 0 likes
It's actually strictly less book keeping. The places you'll need it will always be a subset of if the bound is on the struct
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.