Re: [PATCH v5 5/5] gpu: nova-core: add ChannelIdPool
Miguel Ojeda <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.rust,gmane.comp.video.dri.devel |
|---|---|
| Message-ID | <CANiq72mDrC+43kbj-X0dpSKP6zFM61R3QFPa+2_xKEP-RHUppw@mail.gmail.com> |
On Thu, Aug 13, 2026 at 8:32 PM Yury Norov <[email protected]> wrote: > > Not OK is complicating interfaces and life of your users. No, we don't want to introduce interfaces with unconstrained integers, especially so when we have already types that express what we want. In other words, we don't want to introduce impossible states and error paths that aren't needed -- we want to rule them out statically. That is the point of all of what we are doing with Rust. The unconstrained interface you are proposing is actually the complicated one, because it means now you have to provide more documentation about both the allowed input values and the new error cases. Not only that, you have to provide more tests for all that. And you have to duplicate information that types like `Alignment` already explain if you click on them. And on the callee side, similarly, if someone already has e.g. an `Alignment`, then we don't want users to be forced to convert back to an unconstrained integer just to call the function that requires an alignment to begin with. Now, if a function is truly something that we want to call with e.g. integer literals all the time, then maybe it is worth a workaround -- but those cases are rare, and even then it is likely to just be a wrapper to the normal interface. Cheers, Miguel