Re: [PATCH v7 00/10] rust: add `register!` macro

["Alexandre Courbot" <acourbot@nvidia.com>]

On Thu Feb 26, 2026 at 9:01 PM JST, Dirk Behme wrote:
<snip>
>>> I converted my simple aarch64 TMU timer example [1] over to v7 (many
>>> thanks helping with that!) and gave it a try: It works like with v2.
>>> With that:
>>>
>>> Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
>> 
>> Really appreciated! And I think we are finally converging, so hopefully
>> no more big refactoring ahead. :) Still, please let me know if you saw
>> anything that looked off during the conversion.
>
>
> I was slightly surprised about the `set_` to `with_` change. But 
> thinking about it I think it heavily depends on the point of view:
>
> If you look at it from a physical register point of view I'm used to 
> "set" a register / bit. So looking from physical register point of view 
> I find using `set_` natural.
>
> On the other hand, if we look at the Rust "syntax" you create here like
>
> foo.with_a(4).with_b(9).write(io);
>
> we write to register foo with bits a being 4 and bits b being 9. So we 
> are doing a write *with* some bits set. From this point of view `with_` 
> fits as well.
>
> I think you mentioned that this is discussable. And I think it heavily 
> depends on the point of view you take. So I'm fine either.

This has to do with Rust conventions: we are using a builder pattern,
where fields are set by taking the register by value, and returning the
updated value. Such methods tend to be prefixed with `with_`, whereas
`set_` is typically used for in-plane modification using `&mut self`.

Now AFAICT this is not a *codified* convention, just a rather strong
unwritten one. But it seems adequate to follow it, so users are not
mistaken into thinking the setters do something different than they do.

As to why the builder pattern, this is because it is shorter to write

  io.write(reg.with_foo(true));

than

  mut foo = ...;
  reg.set_foo(true);
  io.write(reg);

and also cleaner as it removes the need for the register variable to be
mutable.