Brendonovich
Use impl Into for where and setparams, create functions
Helpful for when you have a custom type wrapping an i32, for example. You can also borrow strings from structs (no cloning). etc.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| prisma-client-rust | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Dec 13, 2024 2:50am |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
I don't have time to review this just yet, but I will say that a lot of PCR's design decisions revolve around function arguments having discrete types rather than generics. This is done so that I can reliably make function return types generic, which I think is more beneficial. It may work if it's just done for scalar fields, but I'm not certain.
You can also borrow strings from structs (no cloning)
If you're borrowing a string (&String or &str), Into<String> will clone it anyway
I know that it will clone anyways, the point is that the API allows you to borrow it. Tuple struct only containing one type would also be useful, you can just pass it directly (or borrow it), without cluttering the function call with .clone() or .into().
lot of PCR's design decisions revolve around function arguments having discrete types rather than generics
I skipped using impl Into<...> for any generic types because that would just not work
@Brendonovich I believe this PR should be ready to merge, I removed impl Into's for the query params as they would conflict. Could you please review this pr?
In in two minds about this: On one hand, it does offer some dx improvements, especially around string reference types. On the other hand, it disguises memory allocations and lossy number type conversions, and it introduces more monomorphisation for the compiler to deal with. Some magic features are nice but drawing that line is hard.
Personally, I prefer a good DX, and impl Into's remove a lot of boilerplate. If you disagree, I'll probably just keep my repo synced with your master and use that in cargo.