[lmm]

Sum types (and therefore a nice way to do e.g. validation or error handling). A better OO model (particularly when it comes to secondary concerns like serialization or comparison). Safe scoped resource management (with memory-safety without GC as a secondary benefit). A more standard/better-understood way of doing what D calls "compile-time reflection" (if I understand what D's doing there correctly).

[vbezhenar]

Can you produce a string via compile-time functions and compile that string as a Rust fragment? That was incredibly flexible tool in D. The only thing that comes close is Lisp macroses.

[steveklabnik]

Procedural macros take a list of tokens, and you give a list of tokens back, and they're then compiled.

https://doc.rust-lang.org/stable/book/ch19-06-macros.html#ho... (starts with derive, then moves on to attributes. Function-like ones aren't stable yet)

[vbezhenar]

Thanks, that's similar, also I would argue that for inexperienced developer just producing desired text would be a simpler solution (but dangerous).

[TheCoelacanth]

If you use the `quote` crate[1], it's pretty much identical in terms of developer experience.

[1] https://github.com/dtolnay/quote

[lmm]

IMO the fully general version of that is too flexible to be maintainable; it's better to have more constrained/standardised functionality that lets you solve the problems you'd need it for. Generally there are two kinds of things that you would want to be doing at compile time: producing code to handle the fields of a structure in a generic way (which you can do with frunk), or producing delegating wrappers to handle cross-cutting concerns (which you can do up to a point via the combination of built in delegation and first-class functions, though the lack of HKT does make some cases impossible).