Building a runtime reflection system for Rust (Part 3) | Hacker News Reader

Building a runtime reflection system for Rust (Part 3)

osohq.com

60 pointslukastyrychtr10 comments

    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?

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

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.

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

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

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.

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.

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

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.

Isn't it basically building an interpreter in Rust?

Reply on news.ycombinator.com