Comment by wireprotocol | Hacker News Reader

Comment by wireprotocol | Hacker News Reader

Parent Full thread

I really like my experience with rust so far also, but a few caveats:

* try!() Is pretty annoying

* Working effectively with C in non-lexical ways seems to involve some unstable libraries and still requires nightly rust

* Macros are safer, but can't do some things that C macros can. For instance, they are hygienic, which means you can't conjure up new identifiers. For that, you need a syntax plugin, which is very powerful but the APIs aren't stable yet. This goes to the previous point.

* A few annoyances, like warning when you don't use a struct field as "dead code". If I'm interfacing with C I probably need that struct field whether the rust compiler sees it or not, but I don't want to disable all dead code warnings for that.

You can attach the allow(dead_code) attribute to the struct - or even the individual field - which will scope it to that declaration only. Still annoying when you have a lot of them, but better in my opinion than not having dead code warnings on fields, since the use case you describe is the minority of Rust structs that are declared.

Maybe there should be an annotation saying that the layout of a struct is important for ABI compatibility, and it would silence warnings related to the layout.

C FFI structs have to be marked `#[repr(C)]` to guarantee they'll be represented how C structs would be. It might be a reasonable change to implicitly allow dead fields on any struct with a C repr (since using the struct in C effectively makes all of its fields public).

Which unstable libraries are you thinking of?

I think you can silence the dead code warnings by either marking the field `pub` or prefixing it with an underscore.

The `?` operand appended to function calls makes them behave like `try!()`. It's only in nightly currently, on its way to being stabilized.

Awesome, I didn't know that got committed! Hopefully stable soon.

Reply on news.ycombinator.com