|
Certainly looks functional. Some advice to improve it: - For one you'll certainly want to run the linter clippy on your code. - You don't need the `Option::` - This one is a performance optimisation but you don't need three hashmaps - you could leave the valid keys behind in the original serde_json hashmap and just return that at the end. E: You'll want to remove unknown values ofc. Maybe better to move values from the original hashmap than copy them. Check out the `entry` method. - You seem to have forgotten to actually return the 400 in the error case - serde_json has from_slice which avoids the String step gonadic io fucked around with this message at 21:02 on Sep 26, 2023 |
# ? Sep 26, 2023 20:56 |
|
|
# ? May 13, 2024 10:27 |
|
gonadic io posted:Certainly looks functional. Some advice to improve it: thanks for the help! this was the one that was specifically tripping me up though because from_slice has no .get() method. Is there a way to check for the existance of a key without panicking that I was just not finding in my google searches? as far as I can tell, I can only do something like Rust code:
teen phone cutie fucked around with this message at 22:12 on Sep 26, 2023 |
# ? Sep 26, 2023 22:07 |
|
Look at the type signatures of the from_str and from_slice methods. Both can parse into anything that implements the Deserialize trait. If you then click on that and scroll down, you'll see that hashmap is one of those things. It might be that you need a type annotation like you already have.
|
# ? Sep 26, 2023 22:23 |
|
gonadic io posted:Look at the type signatures of the from_str and from_slice methods. Both can parse into anything that implements the Deserialize trait. If you then click on that and scroll down, you'll see that hashmap is one of those things. oh huh i told the method to return a hashmap and.....it just worked. This seems like magic. well thank you again. do you know of any docs that explains this kind of type signature conversion to me like i am a child? Python and Typescript are my only background, and some of this stuff is really hard to wrap my head around. Or rather, is this just something special serde_json is doing that isn't typical? e: we're in business now teen phone cutie fucked around with this message at 22:45 on Sep 26, 2023 |
# ? Sep 26, 2023 22:38 |
|
Reading about the From and Into traits is where I would start.
|
# ? Sep 26, 2023 22:44 |
|
Dijkstracula posted:Reading about the From and Into traits is where I would start. While these are good they don't specifically answer the question. Specifically this is the method signature: https://docs.rs/serde_json/latest/serde_json/fn.from_slice.html It returns a type parameter T, where T is a type that implements the trait Deserialize. If you then look at the docs of that trait it lists all the types that implement it, that you can parse into. Also if you used serde_derive on a struct/enum, those types would implement it too. You absolutely would benefit a lot from reading about traits in general, but the shortest version is that they're a collection of methods. If a type implements a trait, you can call one of those methods on that type. Deserialize is a pretty complicated trait, and not a good first one to investigate (From and Into are much better there). It is a bit magical to have a polymorphic return signature that's freeform (subject to the trait) like that and not too many things do it. The other big one you'll know is the collect method. gonadic io fucked around with this message at 23:02 on Sep 26, 2023 |
# ? Sep 26, 2023 22:59 |
|
gonadic io posted:While these are good they don't specifically answer the question.
|
# ? Sep 27, 2023 00:54 |
|
thanks so much for the direction on this really! I joined 2 different discords this week asking these questions and got a bunch of answers ranging from "I would just have all the validation live in the client" or "i wouldn't aggregate errors at all and just return a single 'form invalid' error" and the best one, "just use a library for this" and other completely useless feedback that isn't teaching me how to use rust
|
# ? Sep 27, 2023 01:37 |
|
yeah I used to hang out in the discord a bunch but it seemed like mostly grouchy old-timers (which I don't necessarily fault them for, if I was answering basic questions over and over again I might turn that way too), but agreed that it isn't often optimal for learning
|
# ? Sep 27, 2023 01:53 |
|
Silly macro question that I can't find a good answer for: I'm building a compiler for a research language in order to write some Rust in anger, and I have a unit test that looks like this, but unfortunately doesn't parse: Rust code:
Rust code:
|
# ? Sep 29, 2023 17:44 |
|
It being nested is a bit annoying. I've made fake little structs likecode:
|
# ? Sep 29, 2023 18:41 |
|
Thanks!gonadic io posted:But it being inside the enum variant means you have to still have an explicit match in there gonadic io posted:Also you'll want to use the `fail` macro instead of just `panic` in your tests.
|
# ? Sep 30, 2023 00:31 |
|
Not that it makes a huge difference, but I think the "let sort" part may benefit from let-else. Also, in the second block you can just code:
Moonlit Knight fucked around with this message at 00:38 on Sep 30, 2023 |
# ? Sep 30, 2023 00:33 |
|
Yeah I elided a bunch of extra fields to keep the example code tidy, but you're not wrong that I forgot about let-else
|
# ? Sep 30, 2023 00:42 |
|
Dijkstracula posted:Thanks! No, that you can't use TestSubClass or something like it until you already do the match into the IvySort::Class variant. I would define a get_class method on IvySort that returns an Option<Class> tbh, then in your test you call expect on that , and can then call matches!, that's how the syn library does it.
|
# ? Sep 30, 2023 06:12 |
|
gonadic io posted:It being nested is a bit annoying. I've made fake little structs like IIRC you can do something like let Some(foo) = bar else { todo!() }; for slightly clearer code than a whole match.
|
# ? Oct 6, 2023 16:28 |
|
I'm trying to wrap my head around this: code:
That part that throws me off is: let s: &[i32] = &a[2..4]; . Wouldn't specifying that you're borrowing cells 2-4 print out 20 30 and 40, not just 30 and 40? I know I'm wrong/missing something here, so why am I wrong?
|
# ? Oct 26, 2023 02:23 |
|
notwithoutmyanus posted:I'm trying to wrap my head around this: Arrays are zero-based, the element at offset 2 is the third element in the array.
|
# ? Oct 26, 2023 02:37 |
|
Also, a .. range excludes its endpoint.
|
# ? Oct 26, 2023 02:58 |
|
Ralith posted:Also, a .. range excludes its endpoint. Ah! Thank you! This is the other side of what I was wondering. I did get the order, but this was what I missed. The other post made sense and I wasn't clear on that I understood reference to 2 = 3rd cell in the array, it was just...this, was what I was trying to understand.
|
# ? Oct 26, 2023 03:05 |
|
For a range that includes both endpoints, you have ..= (which looks a bit strange but is pretty clear in practice).
|
# ? Oct 26, 2023 04:10 |
|
Hi, lifelong Python guy here. Just getting into Rust and have some questions about how people handle things in more stringent type systems. I'm making an HTTP request to an endpoint whose 200 response payload is stable - I do not anticipate its shape changing at all. In Python, I might set up something like a struct mapping to all of the keys in the JSON response from this endpoint. That would be helpful for code completion and documentation for other devs on the project. Using ureq in Rust they suggest doing just that - I can do something like: code:
My understanding is I can either prepend an underscore on fields that are unused, and then remove that underscore later when I use the fields, or I can slap an `#[allow(dead_code)]` at the top of the struct to tell the linter to chill out. My brain tells me that this thing is useful as documentation and an interface. For that reason, I'd rather leave it unmolested - the underscores feel like they would be annoying to remove later and unlikely to clarify any question other than "which fields on this struct are in use in this program right now" - which doesn't seem like a very useful question to have an answer to. For those reasons, I'm erring on just slapping `#[allow(dead_code)]` on it and calling a day. But I'm curious to hear how other people feel about this &or if there's some other way I could be solving this issue.
|
# ? Nov 3, 2023 21:32 |
|
To translate what we would do in Java world, the way to solve this problem is to move all of these empty dataclass structs into their own separate Crate package, call it an "interface", and then tell that entire crate to ignore that, by doing `#![allow(dead_code)]` (with the exclamation point) at the crate's root file. That way, your project will have the important stuff, and all those empty dataclass structs will sit alone in their own special place... which you access by specifying it as a dependency in your Cargo.toml file
|
# ? Nov 3, 2023 21:46 |
|
One of the things people from dynamic types don't really appreciate about static types at first is how easy it is to do the kind of refactoring like later adding a field. There's not really a need to leave stuff like that lying around in case you need it when it's easy to just add it when you need it. I personally would comment it out and leave little note for when I came back to it.
|
# ? Nov 3, 2023 21:48 |
|
If you're using serde_json or similar, you can just leave out the fields you're not interested in. Extra fields aren't an error, and you don't need to spend time parsing them.
|
# ? Nov 3, 2023 22:08 |
|
Also if you're using an ide, which you should be, removing the underscores is like 2 clicks. The two main ones are vscode with rust analyser plug-in, or jetbrains intellij with rust plugin.
|
# ? Nov 3, 2023 22:10 |
|
I appreciate knowing I can just leave them off entirely with serde_json (that is what I'm using, I think) but I think the real driving force behind my desire to leave them in the struct is as documentation of the shape of the response from the API. If I remove them from the struct then I'll have to go inspect the response later if I want one of the other fields that I'm not using right now. Or, worse, I may think that everything in the struct _is the entirety_ of the shape of the response from the API, and not realize that I could also be accessing your mother's phone number, which would be a disaster for my love life. What I'm less worried about is the "difficulty" of the refactor in terms of finger mechanics. Moving them into their own little crate seems reasonable enough I guess, though it feels a little extra for just this little toy example. Feels like a solution I'd reach to if I were mapping a large part of a larger API or something though. The March Hare fucked around with this message at 23:27 on Nov 3, 2023 |
# ? Nov 3, 2023 23:25 |
|
gonadic io posted:I personally would comment it out and leave little note for when I came back to it.
|
# ? Nov 3, 2023 23:43 |
|
The March Hare posted:I appreciate knowing I can just leave them off entirely with serde_json (that is what I'm using, I think) but I think the real driving force behind my desire to leave them in the struct is as documentation of the shape of the response from the API. It's not authoritative, so I wouldn't want to trust it as docs anyway. Tag the whole structure as `non_exhaustive` maybe.
|
# ? Nov 4, 2023 00:16 |
|
Cool, thanks for all the replies everyone - all makes sense.
|
# ? Nov 4, 2023 14:16 |
|
I have a colleague with a design and language situation we're trying to figure out how to solve in Rust. He's porting a Python project that is making heavy use of mixins to handle the multiple inheritance he was dealing with. I don't fully understand all the details myself, but he has state that has to carry along with methods so he can't just go fully virtual. I don't know how to replicate this in Rust because mixins are kind of nerfed in a statically typed language in the first place, and we don't have inheritance to use in the second place. We figure there is probably some macro voodoo we could employ here, but we're just little children and wouldn't know how to even approach that kind of thing. The mixins aren't a truly dynamic situation; they're specified at-once and then the definition is effectively "finished" so I think some kind of macro in one spot could finish the job. It's just figuring out how to fill in a struct while employing various functions in traits simultaneously. I got the notion in more recent versions of Rust that something this wild is actually possible, but that's it. Uhh, I guess a plan B would be to go with a pure compositional approach with entities and components, but then we're putting a lot more overhead on runtime lookups for something that isn't dynamic after its initial definition. Plan C would just be a lot of duplicate typing (copy paste) that will doom us when one of the base, common things changes some day.
|
# ? Dec 6, 2023 08:10 |
|
Isn't a "mixin" essentially just:code:
Are you looking to do that delegation with less typing or something? You certainly could write a macro for that easily enough. In fact it looks like someone already did, though I've never used it so can't speak to whether it's any good.
|
# ? Dec 6, 2023 08:35 |
|
I think every mixin is coming with additional fields in the struct too. Otherwise, just having extension methods or whatever Rust calls it would be pretty obvious. I'm going to check out that link though and you reminded me to actually ask my colleague to verify that problem with the additional state.
|
# ? Dec 6, 2023 17:29 |
|
That mixin crate might just be it. I had done a search originally a few months ago when we were first kicking this around, but didn't find anything. I think I just had a lack of faith in there really being something so I didn't really look. That's on me.
|
# ? Dec 6, 2023 20:19 |
|
Fffuuu. I need to implement a Rust code:
I am in deep crap. Do I have some other options than a circular linked list, implemented with raw pointers? I don't know how to do it but I can learn, can't be much tougher than in ANSI C.
|
# ? Dec 11, 2023 18:23 |
|
I don’t really remember precisely what the Josephus problem is, but what limits you from using a VecDeque? There’s also a linked list implementation in the standard library too. Dijkstracula fucked around with this message at 18:55 on Dec 11, 2023 |
# ? Dec 11, 2023 18:53 |
|
Dijkstracula posted:I don’t really remember precisely what the Josephus problem is, but what limits you from using a VecDeque? Consider a game where there are n children (numbered 1,2,..,n) in a circle. During the game, every kth child is removed from the circle until there are no children left. In which order will the children be removed? And I need to return a list of removed persons, in the removal order. My futile attempt was too slow: Rust code:
|
# ? Dec 11, 2023 19:26 |
|
A "pointer" can be something that indexes into an array. You could have a data structure that contains a next_index and prev_index and update those as you iterate thru.
|
# ? Dec 11, 2023 19:32 |
|
VecDeque helped somewhat, but not still enough. Maybe smaller integers? I finally actually timed what takes so long, and I realized printing! Rust code:
Pointer usage will be saved for another day. Thanks...
|
# ? Dec 11, 2023 19:57 |
|
|
# ? May 13, 2024 10:27 |
|
Why k - 1? For k = 1 every child should be removed in order, but in your code, idx would be constant, right? Edit: oh, got it. You need to decrement the index because the queue has one fewer element. Moonlit Knight fucked around with this message at 23:14 on Dec 11, 2023 |
# ? Dec 11, 2023 23:12 |