On Tue Mar 17, 2026 at 9:56 PM JST, Gary Guo wrote: > On Tue Mar 17, 2026 at 6:50 AM GMT, Alice Ryhl wrote: >> On Tue, Mar 03, 2026 at 05:22:53PM +0100, Danilo Krummrich wrote: >>> From: Gary Guo <[email protected]> >>> >>> Currently, `CoherentAllocation` is concecptually a DMA coherent container >>> of a slice of `[T]` of runtime-checked length. Generalize it by creating >>> `dma::Coherent<T>` which can hold any value of `T`. >>> `Coherent::alloc_with_attrs` is implemented but not yet exposed, as I >>> believe we should not expose the way to obtain an uninitialized coherent >>> region. >>> >>> `Coherent<[T]>` provides a `len` method instead of the previous `count()` >>> method to be consistent with methods on slices. >>> >>> The existing type is re-defined as a type alias of `Coherent<[T]>` to ease >>> transition. Methods in use are not yet removed. >>> >>> Signed-off-by: Gary Guo <[email protected]> >>> Signed-off-by: Danilo Krummrich <[email protected]> >> >> I see you have both `size()` and `len()`. I think it would be clearer to >> rename `size()` to `len_bytes()`. > > This is an API that already exists and I simply moved it around so it is > implemented for all types, not just `[T]`. > > I also think that `size()` quite unambiguously means the size in bytes (like, > in > all allocation and I/O APIs, `size` means size of object in bytes); I don't > see > much benefit in renaming it `len_bytes`.
Agreed, furthermore `len` is used in the standard library so the pattern of it returning a number of elements is pretty established. Generally speaking I tend to prefer having the units mentioned in the doccomment rather than the method name.
