4 ms·

Building a runtime reflection system for Rust (Part 3)

60 points by lukastyrychtr 6y ago

RcouF1uZ4gsC 6y ago
tuple_impls! {} tuple_impls! { A } tuple_impls! { A B } tuple_impls! { A B C } // .. more macro invocations follow // we support method arities up to 16 tuple_impls! { A B C D E F G H I J K L M N O P } Rust really needs the equivalent of C++ variadic templates. Is there any work ongoing on it?
- Rangi42 6y ago
  From the article: > There's an open issue for something like this: Variadic generics[1]. But so far every attempt at an RFC has been closed or postponed. [1]: https://github.com/rust-lang/rfcs/issues/376 https://github.com/rust-lang/rfcs/issues/376
  - RcouF1uZ4gsC 6y ago
    Thanks, I somehow missed that part when reading. I would guess that two big issues for that are lack of function overloading and that macros are pretty good. A lot of the patterns of working with variadics in c++ take advantage of function overloading. Without function overloading, those patterns can become harder. Secondly, Rust macro system is crazily powerful especially procedural macros. That power disincentivizes developing other approaches to meta programming. In C++ macros are clunky and dangerous, and that has incentivized developing more type based meta programming techniques to get away from C macros.
    - ibraheemdev 6y ago
      One problem with the macros approach is that you get really hard to understand error messages. For example, if a user wrote a method where one of the arguments did not implement ToPolarValue, they would get the following error: fn blah(blah: Blah) ^^^^^^^^^^^^^^^^^^^ the trait bound Method<_, _> is not satisfied As opposed to something like this with variadic generics: fn blah(blah: Blah) ^^^^ the trait bound ToPolarValue is not satisfied
      - the_duke 6y ago
        There is an accepted and partially implemented RFC [1] that can improve proc macro error messages a lot. Sadly it hasn't been worked on in years. [1] https://github.com/rust-lang/rust/issues/54140 https://github.com/rust-lang/rust/issues/54140
        ibraheemdev 6y ago
        proc macro diagnostics are a cool feature, but they would not help here. Here, macros are being used to generate implementations of a trait. If the trait bound is not satisfied, you have no way of knowing why other than that there was no implementation generated for it, hence the confusing error message. With variadic generics however, you could write something like: Fn(..Args) -> T which I assume would let the compiler know why the trait bound is not satisfied and output a nicer error message.
throw_m239339 6y ago
Isn't it basically building an interpreter in Rust?
DethNinja 6y ago
Is there any plans to officially add a runtime reflection system to Rust standard library? It feels really weird to me that a relatively new language doesn’t include reflection out of box.
- nestorD 6y ago
  At the moment no [0]. My undertsanding of the arguments is that macros and the type system already get you 90% of the way at compile time (while being able to cause compile time error if you made a mistake rather than obscure run time crashes) and that reflection has no benefit large enough to warrant the additional complexity and bug opportunities. [0]: https://internals.rust-lang.org/t/solid-reflection-in-rust https://internals.rust-lang.org/t/solid-reflection-in-rust
- souprock 6y ago
  The reduced runtime overhead, including optional temptations, is what makes Rust an interesting and modern language. Language design took a wrong turn in the 1990s, leaving us stuck using very old languages from the 1970s.

60 points by lukastyrychtr 6y ago

tuple_impls! {} tuple_impls! { A } tuple_impls! { A B } tuple_impls! { A B C } // .. more macro invocations follow // we support method arities up to 16 tuple_impls! { A B C D E F G H I J K L M N O P } Rust really needs the equivalent of C++ variadic templates. Is there any work ongoing on it?

Rangi42 6y ago
From the article: > There's an open issue for something like this: Variadic generics[1]. But so far every attempt at an RFC has been closed or postponed. [1]: https://github.com/rust-lang/rfcs/issues/376 https://github.com/rust-lang/rfcs/issues/376
- RcouF1uZ4gsC 6y ago
  Thanks, I somehow missed that part when reading. I would guess that two big issues for that are lack of function overloading and that macros are pretty good. A lot of the patterns of working with variadics in c++ take advantage of function overloading. Without function overloading, those patterns can become harder. Secondly, Rust macro system is crazily powerful especially procedural macros. That power disincentivizes developing other approaches to meta programming. In C++ macros are clunky and dangerous, and that has incentivized developing more type based meta programming techniques to get away from C macros.
  - ibraheemdev 6y ago
    One problem with the macros approach is that you get really hard to understand error messages. For example, if a user wrote a method where one of the arguments did not implement ToPolarValue, they would get the following error: fn blah(blah: Blah) ^^^^^^^^^^^^^^^^^^^ the trait bound Method<_, _> is not satisfied As opposed to something like this with variadic generics: fn blah(blah: Blah) ^^^^ the trait bound ToPolarValue is not satisfied
    - the_duke 6y ago
      There is an accepted and partially implemented RFC [1] that can improve proc macro error messages a lot. Sadly it hasn't been worked on in years. [1] https://github.com/rust-lang/rust/issues/54140 https://github.com/rust-lang/rust/issues/54140
      - ibraheemdev 6y ago
        proc macro diagnostics are a cool feature, but they would not help here. Here, macros are being used to generate implementations of a trait. If the trait bound is not satisfied, you have no way of knowing why other than that there was no implementation generated for it, hence the confusing error message. With variadic generics however, you could write something like: Fn(..Args) -> T which I assume would let the compiler know why the trait bound is not satisfied and output a nicer error message.

throw_m239339 6y ago

Isn't it basically building an interpreter in Rust?

DethNinja 6y ago

Is there any plans to officially add a runtime reflection system to Rust standard library? It feels really weird to me that a relatively new language doesn’t include reflection out of box.

nestorD 6y ago
At the moment no [0]. My undertsanding of the arguments is that macros and the type system already get you 90% of the way at compile time (while being able to cause compile time error if you made a mistake rather than obscure run time crashes) and that reflection has no benefit large enough to warrant the additional complexity and bug opportunities. [0]: https://internals.rust-lang.org/t/solid-reflection-in-rust https://internals.rust-lang.org/t/solid-reflection-in-rust
souprock 6y ago
The reduced runtime overhead, including optional temptations, is what makes Rust an interesting and modern language. Language design took a wrong turn in the 1990s, leaving us stuck using very old languages from the 1970s.