On Mon Mar 2, 2026 at 1:42 PM JST, Eliot Courtney wrote: > On Mon Mar 2, 2026 at 12:08 PM JST, John Hubbard wrote: >> On 3/1/26 7:03 PM, Alexandre Courbot wrote: >>> On Mon Mar 2, 2026 at 11:22 AM JST, Eliot Courtney wrote: >>>> On Sat Feb 28, 2026 at 3:11 PM JST, John Hubbard wrote: >>>>> On 2/26/26 7:50 AM, Eliot Courtney wrote: >>>>>> Add sync and async command queue API and the type infrastructure to know >>>>>> what reply is expected from each `CommandToGsp`. >> ... >>>> For lack of a better idea i suggest send_and_wait_for_reply + >>>> send_no_reply for now. >>> >>> One important detail IMHO is that the API cannot be misused, i.e. you >>> cannot call the fire-and-forget send method on a command that expects a >>> reply. So the risk is mostly when adding support for a new command - but >>> if that step is done properly, users will be directed to the right >>> method by the compiler. >> >> Naming is not *just* about risk of someone misusing it. It's about >> being able to read things on the screen and having a good chance of >> understanding it. >> >>> >>> This, I think, allows us to tolerate more ambiguity in the method names, >>> as long as their documentation makes up for it. We all agree that >> >> Really, no. Let's do our best on naming, *in addition* to the documentation >> and having Rust help lock things down. > > I personally agree with this take, and if it takes a verbose name to > make it clear then I feel it's unfortunate but there's no way around it. > Especially since we have a few different concepts to distinguish between. > > Agreed that we are safe writing it since the type system will help us > though. So mainly just optimising on how easy it is to read. > > At least the current usages don't seem to end up on long lines, so I > don't think it will introduce too much noise to have the function names > be a bit longer.
Alright, we're still far from things like rmDeviceGpuLocksReleaseAndThreadStateFreeDeferredIntHandlerOptimized() (not making this up) so I guess we can afford some extra clarity in our method names. :)
