Hacker News Reader

Comment by queuebert | Hacker News Reader

Also a ton of ALL CAPS TYPES. Are we seriously throwing out all of the standard Rust naming conventions to adopt the ancient Windows naming-as-typing crap?

View on HN

That doesn't bother me per-se - those all caps names are pretty much all directly from the standard C bindings, and it makes sense to preserve that naming for the sake of having that 1:1 mapping with the ground truth C definition.

The actual issue here is that this "simple driver in Rust" is having to touch those direct C bindings at all - if Microsoft is going to advertise that they have support for writing drivers in Rust, that should presumably mean an API surface that's native to the language.

I believe Rust has added the ability to mark FFI functions as safe to call at their definition site (https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safe-...)

That way functions can be marked as accurate/"ok" to call in safe code by the author of the bindings. They could absolutely not be safe; in that case, the binding author is in error marking it so.

> that should presumably mean an API surface that's native to the language.

It reads pretty naturally to me as referring to the implementation of the driver.

I see your point, but it makes it hard for Rust programmers to grok the code, as all caps denotes a constant. Even enums are camel case.

This is pretty normal for Rust code that FFIs to external libraries.

There's a lot more complexity in writing FFI code - you have to think very carefully about everything you do. Case convention is a triviality here.

In Delphi the Windows types are declared as-is, ie with all caps, but then most of them are aliased to more Pascal-like names.

So you can use TRect and TPoint and pass those to PtInRect[1] which expects RECT and POINT respectively.

[1]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/...

Reply on news.ycombinator.com