Re: [PATCH v8 1/1] rust: pci: add extended capability and SR-IOV support

On Mon Aug 24, 2026 at 4:46 PM BST, Gary Guo wrote:
> On Mon Aug 24, 2026 at 4:21 PM BST, Alexandre Courbot wrote:
>> On Mon Aug 24, 2026 at 8:59 PM JST, Gary Guo wrote:
>>>
>>> Aesthetic and ergnomics is a big part of code, and is what make people like
>>> Rust. In a world where less code is produced by human, I think it's especially
>>> important that code remains easily human readable.
>>>
>>> You can probably already tell that I have very strong opinion about this.
>>
>> So do I, and the fact we both have opinions on the matter is irrelevant.
>> "It looks horrible" is not an argument.
>
> Ergnomics is a perfectly valid argument and often a key factor in design
> decisions. Otherwise we'd make all functions carry extra argument indicating the
> context they're in and would require sleeping functions to carry such token
> types. We rejected that approach because it'll infect all functions and make
> Rust code look horrible.
>
> Everything is a trade-off. Whether to perform extra validation vs better
> ergnomics is a genuine thing that needs deliberation. A outright dismissal of
> the argument is itself a non-constructive argument.
>
>>
>> Safety and correctness are the very reason for using Rust, not that it
>> looks better or is more ergonomic. It often does, it sometimes doesn't
>> (see the hoops we have to jump through to cast a pointer for instance),
>> and when it does, that is usually to improve correctness, not to
>> compromise it. The reason we go through these lengths is to remove
>> issues and footguns at build-time, and this is exactly what these
>> helpers do because `as` is one of the footguns.
>
> There's nothing unsafe or incorrect in using `as`. Your suggested code is no
> more correct than Zhi's current version. You just added some extra check to some
> constant that will never change, and we know will not produce error. My argument
> is that that makes the syntax horrible and it's not a trade-off worth making.
>
> When we create new abstractions, we try to make thing has minimal overhead.
> Otherwise we'd be using a GC language and that'd solve memory safety issues.
> Your abstraction is not zero-cost -- it sacrifices compilation-time, binary size
> (for debug info) and it adds a significant cognitive overhead for writing code.

The code here is const eval, so debug info doesn't apply. And for the specific
cases of functions containing only a single cast, as all instructions are going
to be optimized out debug info should (hopefully) not be left too. However,
metadata sizes would still be larger because rustc record all inlined functions
within its MIR.

Anyway, this is really more an auxiliary point, my main focus is on the
cognitive complexity.

Best,
Gary