4 ms·

I think we pretty much agree on everything then. My only complain about autocxx remains that it does not require `unsafe`, but if they adopt the same fix that

I think we pretty much agree on everything then. My only complain about autocxx remains that it does not require `unsafe`, but if they adopt the same fix that the `cxx` crate wants to adopt, that complain is gone. I hope the Chromium devs would be "ok" with such a small amount of unsafe code that condenses the proofs of all APIs being wrapped. We kind of tossed aside the discussion of unsafe vs safe macros, but I'd understand some people see that differently (macros expand Rust code, but IMO they are not that different from generics, and we do have safe and unsafe generics; right now, AFAICT, we only have safe macros).

Rusky 6y ago
Yeah, I do think it might be interesting (if somewhat of a backwards compatibility problem) to introduce the concept of an "unsafe macro." Along with https://github.com/rust-lang/rfcs/pull/2585 https://github.com/rust-lang/rfcs/pull/2585 it would really emphasize the proof obligation-vs-discharge model of `unsafe`.
- fluffything 6y ago
  I think that would be worth doing, but more than the backward compat problem, the main complication I see would be in the syntax/grammar/macro expansion. Like, say we wanted to make cxx or autocxx macros unsafe. We'd need to allow at item scope writing this: mod foo { unsafe { my_unsafe_macro!() } } and we'd "somehow" have to check that unsafe macros are only expanded within unsafe "scopes", rejecting the program otherwise (can't be a type error because we can't do type checking before macro expansion). Also, these unsafe scopes would need to export all the items, etc. I don't know. Seems like a lot of contortion for something that could be solved with just a rename like other have proposed, e.g., unsafe_autocxx_include!(...); Might be worth opening an internal threads about this. Maybe Centril could shed more like on how hard this would actually be. Most (all?) macros that I regularly use are sound (the derives, println!, debug!, offset_of!, pin_mut!...). So it might also be worth looking into how common of a problem this is. I've seen soundness bugs in macros before (offset_of!), but these were always bugs. This is the first time I recall a macro that's unsound by design.

Rusky 6y ago

Yeah, I do think it might be interesting (if somewhat of a backwards compatibility problem) to introduce the concept of an "unsafe macro." Along with https://github.com/rust-lang/rfcs/pull/2585 https://github.com/rust-lang/rfcs/pull/2585 it would really emphasize the proof obligation-vs-discharge model of `unsafe`.

fluffything 6y ago
I think that would be worth doing, but more than the backward compat problem, the main complication I see would be in the syntax/grammar/macro expansion. Like, say we wanted to make cxx or autocxx macros unsafe. We'd need to allow at item scope writing this: mod foo { unsafe { my_unsafe_macro!() } } and we'd "somehow" have to check that unsafe macros are only expanded within unsafe "scopes", rejecting the program otherwise (can't be a type error because we can't do type checking before macro expansion). Also, these unsafe scopes would need to export all the items, etc. I don't know. Seems like a lot of contortion for something that could be solved with just a rename like other have proposed, e.g., unsafe_autocxx_include!(...); Might be worth opening an internal threads about this. Maybe Centril could shed more like on how hard this would actually be. Most (all?) macros that I regularly use are sound (the derives, println!, debug!, offset_of!, pin_mut!...). So it might also be worth looking into how common of a problem this is. I've seen soundness bugs in macros before (offset_of!), but these were always bugs. This is the first time I recall a macro that's unsound by design.