Re: [PATCH v5 5/5] gpu: nova-core: add ChannelIdPool
Burak Emir <[email protected]>
| Newsgroups | org.kernel.vger.rust-for-linux,dev.linux.lists.nova-gpu,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CABwQupNA=NuctKz0FRaJsWowf+=24C_o7u8twFFeUZ+dq6u+Jw@mail.gmail.com> |
On Mon, Aug 17, 2026 at 4:08 PM Danilo Krummrich <[email protected]> wrote: > > On Mon Aug 17, 2026 at 3:02 PM CEST, Gary Guo wrote: > > Now, with `NonZero` or `Bounded`, we are doing none of that. The only thing here > > is that there is a range restriction. Other than the value restriction > > themselves, they carry no other semantic meanings. How you interpret these types > > still fully depend on the API that accepts them. Therefore, it is very common > > that you'd be using these with literals, and it becomes an ergnomic pain. > > I agree that NonZero and Bounded are on the weaker end of the argument. But > there's still the flexibility argument. > > The API itself, i.e. alloc_area(), does not need to bother with how the value is > checked. I.e. is it a runtime check, compile or build time check, or is it even > unchecked (or panicking) because we can derive the invariant from another type. > To add a minor point to this, if rustc could figure out that a suitable non-zero number literal can be treated as NonZero<usize>, we'd not need a macro and it would all be very ergonomic... cheers, - Burak