Rick van der Wal
Rick van der Wal
If we were to vote, I would be in favor. I would love to be able to turn this pattern: ```rust #[get("/post/")] pub async fn view_post(id: i32, db: MyDB) {...
> However, I think the way we should approach this is to keep the existing PhyRxTx and add a trait impl for the radio-hal traits. The reason is both that...
I locally added generic parameters to radio-hal's traits, but came across the following problems while implementing `PhyRxTx` for them: * `Receive`'s `get_received` method requires a mutable reference to a buffer...
> the `radio-hal` base traits are perhaps more fine-grained than `PhyRxTx`, the idea is that you would to combine `Transmit` or `Receive` with `Channel` and `State` to compose the required...
I guess it's because new trait implementations are not commonly considered breaking changes (even though [they can be](https://std-dev-guide.rust-lang.org/breaking-changes/new-trait-impls.html)). Suppose your crate `b` depends on crate `a` at version `1.0`. You...
Are there downsides to tracking fixture migrations in the `_sqlx_migrations` table? They're distinct in the way that they don't alter table structure, and that you wouldn't run them in production...
It's true that changing the fixtures would result in an error. If that's a regular occurrence in your workflow, this change is indeed not helpful. I'm not sure about other...
That is a more traditional way to create fixtures, but I disagree that it's the only way it *should* be. It often requires changing several fixtures after each table structure...